Ambulatory medicament pumps with selective alarm muting

ABSTRACT

Ambulatory medicament devices that provide therapy to a subject, such as blood glucose control, are disclosed. Disclosed systems and methods can implement one or more features that improve the user experience, by modifying delivery of therapy to a subject after determining that a possible occlusion exists in a medicament delivery system, monitoring the status of an ambulatory medical device and the health condition of a subject that receives therapy from the ambulatory medical device and annunciating alarm condition when necessary, selectively muting alarm annunciations while a Do Not Disturb mode is activated, implementing various power saving modes to save power, controlling operation of the device and medicament delivery based on the user gesture controls, and controlling medicament delivery based on a condition of the ambulatory medicament device.

INCORPORATION BY REFERENCE

This application is a continuation of PCT Application No.PCT/US2021/0064228, filed Dec. 17, 2021, which claims priority to U.S.Provisional Patent Application Nos. 63/128,428, filed Dec. 21, 2020;63/167,563, filed Mar. 29, 2021; 63/216,177, filed Jun. 29, 2021;63/239,365, filed Aug. 31, 2021; 63/169,112, filed Mar. 31, 2021;63/151,565, filed Feb. 19, 2021; 63/261,290, filed Sep. 16, 2021;63/152,744, filed Feb. 23, 2021; 63/157,541, filed Mar. 5, 2021;63/152,716, filed Feb. 23, 2021; 63/168,203, filed Mar. 30, 2021;63/212,521, filed Jun. 18, 2021; 63/139,210, filed Jan. 19, 2021;63/238,670, filed Aug. 30, 2021; 63/276,481, filed Nov. 5, 2021;63/215,857, filed Jun. 28, 2021; 63/183,900, filed May 4, 2021;63/249,975, filed Sep. 29, 2021; 63/194,126, filed May 27, 2021;63/263,602, filed Nov. 5, 2021; and 63/264,645, filed Nov. 29, 2021. PCTApplication No. PCT/US2021/0064228 claims priority to PCT ApplicationNo. PCT/US2021/072742, filed Dec. 3, 2021, which claim priority to U.S.Provisional Application No. 63/122,427, filed Dec. 7, 2020. The entirecontents of each application referenced in this paragraph are herebyincorporated by reference herein for all purposes and made part of thisspecification. Any and all applications for which a foreign or domesticpriority claim is identified in the Application Data Sheet as filed withthe present application are hereby incorporated by reference under 37CFR 1.57.

BACKGROUND Technical Field

This disclosure relates to glucose control systems, including medicaldevices that provide glucose control therapy to a subject, glucose levelcontrol systems, and ambulatory medicament pumps that deliver medicamentto the subject to control blood glucose level in the subject.

Description of Related Art

Sustained delivery, pump driven medicament injection devices generallyinclude a delivery cannula mounted in a subcutaneous manner through theskin of the subject at an infusion site. The pump draws medicine from areservoir and delivers it to the subject via the cannula. The injectiondevice typically includes a channel that transmits a medicament from aninlet port to the delivery cannula which results in delivery to thesubcutaneous tissue layer where the delivery cannula terminates. Someinfusion devices are configured to deliver one medicament to a subjectwhile others are configured to deliver multiple medicaments to asubject.

SUMMARY

Blood glucose control systems and ambulatory medical devices thatprovide therapy to a subject, such as blood glucose control, aredisclosed. Disclosed systems and devices can implement one or morefeatures that improve the user experience, such as software updatetechniques that avoid interrupting delivery of therapy, gesture-basedcontrol of therapy delivery, automatic resumption of therapy after auser-initiated pause, improved alarm management, display of autonomouslycalculated dosing recommendations, wide area network connectivity, andsecurity features.

BRIEF DESCRIPTION OF THE DRAWINGS

The systems, methods, and devices of this disclosure each have severalinnovative aspects, no single one of which is solely responsible for allof the desirable attributes disclosed herein. Details of one or moreimplementations of the subject matter described in this specificationare set forth in the accompanying drawings and the description below.The drawings are provided to illustrate certain aspects of the subjectmatter described herein and not to limit the scope thereof.

FIG. 1A illustrates an example blood glucose control system thatprovides blood glucose control via an ambulatory medicament pump.

FIG. 1B illustrates another example blood glucose control system thatprovides blood glucose control via an ambulatory medicament pump.

FIG. 1C illustrates a further example blood glucose control system thatprovides blood glucose control via an ambulatory medicament pump.

FIG. 2A shows a block diagram of an example blood glucose controlsystem.

FIG. 2B shows a block diagram of another example blood glucose controlsystem.

FIG. 2C shows a block diagram of another example blood glucose controlsystem.

FIG. 2D shows a block diagram of another example blood glucose controlsystem.

FIG. 3 is a schematic of an example glucose control system that includesan electronic communications interface.

FIG. 4A shows a block diagram of an example blood glucose control systemin online operation mode.

FIG. 4B shows a block diagram of an example blood glucose control systemin offline operation mode.

FIG. 5A illustrates a perspective view of an example ambulatory medicaldevice.

FIG. 5B illustrates a cross sectional view of the ambulatory medicaldevice shown in FIG. 5A.

FIG. 6 illustrates different modules that may be included in an exampleambulatory medical device.

FIG. 7 illustrates various methods and links that AMD may establish aconnection with a host computing system.

FIG. 8 is a flow diagram showing an example of a computer-implementedmethod that may be used by an AMD in order to detect and download anapplication update.

FIG. 9 is a flow diagram showing an example of a computer-implementedmethod that may be used by an AMD to install a down-loaded applicationupdate without interrupting the therapy provided to a subject.

FIG. 10 is a flow diagram showing an example of a computer-implementedmethod that may be used by an AMD to install a second update downloadedfrom a host computing system and switch control of the AMD from a firstapplication to the second application without interrupting the therapyprovided to a subject.

FIG. 11 is a flow diagram showing an example of a computer-implementedmethod that may be used by an AMD to install a second applicationdownloaded from a host computing system, verify and switch control ofthe AMD from a first application to the second application withoutinterrupting the therapy provided to a subject, when the secondapplication satisfies a minimum set of operation conditions.

FIG. 12 is a flow diagram showing an example of a computer-implementedmethod that may be used to respond to detection of an application faultduring the execution of a first version of an application and switchingcontrol of the AMD to a second version an application installed on theAMD.

FIG. 13 is a flow diagram showing an example of a computer-implementedmethod that may be used to respond to detection of an application faultduring the execution of a first version of an application and switchingcontrol of the AMD to a second version an application installed on theAMD and/or downloading a third version of the application.

FIG. 14. is a block diagram, illustrating an example networkconfiguration wherein the AMD is directly connected to a computingsystem and the computing system shares the therapy reports with one ormore display systems and the AMD.

FIG. 15 is a flow diagram illustrating an example method that may beused by a computing system, to generate and share a therapy report basedon encrypted therapy data received from an AMD.

FIG. 16. is a block diagram, illustrating an example network and dataflow configuration wherein the AMD is directly connected to a computingsystem and the computing system generates and sends alerts to one ormore display systems and the AMD.

FIG. 17 is a flow diagram illustrating an example method that may beused by a computing system, to generate and send an alert to one or moreauthorized devices.

FIG. 18 illustrates the interconnection among modules and procedures inAMD involved in receiving, accepting and/or canceling therapy changerequest.

FIG. 19 is a flow diagram illustrating an example method that may beused by an AMD to allow a user to change the configuration of theambulatory medicament device using a touch screen user interface.

FIG. 20A is an illustration of the touchscreen display of an example AMDafter the touch screen is waked/unlocked by a wake action of a user andbefore the first user gesture is received.

FIG. 20B is an illustration of an example touchscreen display that mayprompt the user to enter a predetermined series of inputs for the firstgesture or second gesture.

FIG. 20C is an illustration of an example therapy change user interface.

FIG. 20D is an illustration of another therapy change user interface ona touchscreen display.

FIG. 21 is a flow diagram illustrating an example method that may beused by an AMD to generate an alarm status indicator.

FIG. 22 is a flow diagram illustrating an example method that may beused to cancel a therapy change using a touchscreen interface.

FIG. 23A is an illustration of a touchscreen display alerting the userthat the delivery of one or more medicaments will occur.

FIG. 23B is an illustration of a touchscreen display showing that amedicament is being delivered to the user.

FIG. 24 is a block diagram illustrating the interconnection amongmodules and procedures in AMD involved in receiving, accepting and/orcanceling a therapy suspension request.

FIG. 25 is a flow diagram illustrating an example method for receivingand implementing a suspension request, which may be implemented by anAMD

FIG. 26 illustrates a plurality of screens that the ambulatory medicaldevice may display when a user pauses therapy.

FIG. 27 is a flow diagram illustrating an example method of resuming asuspended therapy that may be implemented by an AMD.

FIG. 28 illustrates a plurality of screens that the ambulatory medicaldevice may display when a user resumes therapy.

FIG. 29 is a block diagram illustrating the interconnection amongmodules and procedures in AMD involved in changing the settings of theAMD.

FIG. 30 is a flow diagram illustrating an example method that may beused by an AMD to allow a user to change a setting of the AMD using auser generated passcode or an override passcode.

FIG. 31 is a flow diagram illustrating an example method that may beused by an AMD to allow a user to change a setting of the AMD using auser generated passcode or an override passcode.

FIG. 32 is a schematic diagram illustrating the interconnection amongmodules and procedures in an AMD involved in monitoring the status ofthe AMD and/or the subject and generating alarms when an alarm conditionis met.

FIG. 33 is a flow diagram illustrating an example procedure that may beused by the alarm system of an AMD to annunciate an alarm condition uponreceiving a status information that satisfies an alarm condition.

FIG. 34 is a block diagram illustrating the interconnection amongmodules and procedures in AMD involved in monitoring the condition ofthe AMD and generating alerts when a device malfunction is detected.

FIG. 35 is a flow diagram illustrating an example procedure that may beused by the alert system of an AMD to monitor the operation of an AMDand generate alerts when a device malfunction is detected.

FIG. 36 is a schematic diagram illustrating an ambulatory medical devicethat provides the user with various options for providing medicament.

FIG. 37 is a flow diagram of a process for providing options for mealdosage selection on an ambulatory device.

FIG. 38 is another flow diagram of a process for providing options formeal dosage selection on an ambulatory device.

FIG. 39 is a series of screen displays showing a user initiating theactivation of meal dosage on an ambulatory device.

FIG. 40 is a series of screen displays showing a user activating mealdosage on an ambulatory device.

FIG. 41 is a series of screen displays showing a user activating mealannouncement on an ambulatory device.

FIG. 42 is a series of screen displays showing a user inputting thetotal number of units on an ambulatory device.

FIG. 43 is a series of screen displays showing an ambulatory medicaldevice delivering the units and cancelling the delivery of the units.

FIG. 44 is a schematic illustrating a computer system that can beimplemented in various embodiments of the described subject matter.

FIG. 45A is a schematic illustrating an example ambulatory medicamentpump that is configured to maintain delivery of therapy to a subjectafter determining that a possible occlusion exists in a medicamentdelivery system.

FIG. 45B is a schematic illustrating an example occlusion detectionsystem.

FIG. 46A is a flow chart flow diagram illustrating an example methodthat may be used by an AMD to maintain delivery of therapy to a subjectafter determining that a possible occlusion exists in a medicamentdelivery system.

FIG. 46B is a flow chart flow diagram illustrating an example methodthat that may be used by an occlusion detection system to maintaindelivery of therapy to a subject after determining that a possibleocclusion exists in a medicament delivery system.

FIG. 47 is a flow diagram illustrating an example procedure to activatea Do Not Disturb mode in an AMD.

FIG. 48 is a flow diagram illustrating another example procedure toactivate a Do Not Disturb mode in an AMD.

FIG. 49 is a flow diagram illustrating an example procedure that may beused by the alarm system of an AMD to escalate non-urgent alarms.

FIG. 50 illustrates a plurality of screens that may be displayed on atouch screen display of an AMD for activating Do Not Disturb mode on theAMD.

FIG. 51 illustrates a plurality of screens that may be displayed on atouch screen display of an AMD for deactivating Do Not Disturb mode onthe AMD.

FIG. 52 is an illustration of a user interface provided on a touchscreen display for viewing alarm notification details.

FIG. 53A and FIG. 53B are illustrations of a user interface provided ona touch screen display for accessing an alarm notifications screen whenDo Not Disturb mode is activated and when the touch screen display islocked.

FIG. 54A and FIG. 54B illustrations of a user interface provided on atouch screen display for accessing an alarm notifications screen when DoNot Disturb mode is activated and when the touch screen display isunlocked.

FIG. 55 illustrates a user interface that may be displayed by anambulatory medical device in a power saving mode.

FIG. 56 is a flow diagram illustrating an example procedure to activatea power saving mode of an ambulatory medical device.

FIG. 57 is a flow diagram illustrating an example procedure for tapinteraction in a power saving mode of an ambulatory medical device.

FIG. 58 is a flow diagram illustrating another example procedure for tapinteraction in a power saving mode of an ambulatory medical device.

FIG. 59 is a flow diagram illustrating another example procedure for tapinteraction in a power saving mode of an ambulatory medical device.

FIG. 60 is a flow diagram illustrating another example procedure for tapinteraction in a power saving mode of an ambulatory medical device.

FIG. 61 is a flow diagram illustrating another example procedure for tapinteraction with an ambulatory medical device.

FIG. 62 is a flow diagram illustrating an example procedure to controlan operation of an ambulatory medical device pump based on motiondetection.

FIG. 63 is a flow diagram illustrating an example procedure to controlan operation of an ambulatory medical device pump after freefall motionhas ended.

FIG. 64 is a flow diagram illustrating an example procedure to receivean alarm acknowledgement from a user.

FIG. 65 is a flow diagram illustrating an example procedure to unlock atouchscreen of an ambulatory medical device by motion.

FIG. 66 is a flow diagram illustrating an example procedure to enter agesture password to unlock a touchscreen of an ambulatory medical deviceby motion.

FIG. 67 is a flow diagram illustrating an example procedure to delivermedicament to a subject by motion control.

DETAILED DESCRIPTION

Some embodiments described herein pertain to medicament infusion systemsfor one or more medicaments and the components of such systems (e.g.,infusion pumps, medicament cartridges, cartridge connectors, lumenassemblies, infusion connectors, infusion sets, etc.). Some embodimentspertain to methods of manufacturing infusion systems and componentsthereof. Some embodiments pertain to methods of using any of theforegoing systems or components for infusing one or more medicaments(e.g., pharmaceutical, hormone, etc.) to a subject. As an exemplaryillustration, an infusion system may include an infusion pump, which caninclude one or more medicament cartridges or can have an integratedreservoir of medicament. An infusion system may include medicamentcartridges and cartridge connectors, but not a pump. An infusion systemmay include cartridge connectors and an infusion pump, but notmedicament cartridges. An infusion system may include infusionconnectors, a lumen assembly, cartridge connectors, an infusion pump,but not medicament cartridges or an infusion set. A blood glucosecontrol system can operate in conjunction with an infusion system toinfuse one or more medicaments, including at least one blood glucosecontrol agent, into a subject. Any feature, structure, component,material, step, or method that is described and/or illustrated in anyembodiment in this specification can be used with or instead of anyfeature, structure, component, material, step, or method that isdescribed and/or illustrated in any other embodiment in thisspecification. Additionally, any feature, structure, component,material, step, or method that is described and/or illustrated in oneembodiment may be absent from another embodiment.

Some embodiments described herein pertain to medicament infusion systemsfor one or more medicaments and the components of such systems (e.g.,infusion pumps, medicament cartridges, cartridge connectors, lumenassemblies, infusion connectors, infusion sets, etc.). Some embodimentspertain to methods of manufacturing infusion systems and componentsthereof. Some embodiments pertain to methods of using any of theforegoing systems or components for infusing one or more medicaments(e.g., pharmaceutical, hormone, etc.) to a subject. As an exemplaryillustration, an infusion system may include an infusion pump, which caninclude one or more medicament cartridges or can have an integratedreservoir of medicament. An infusion system may include medicamentcartridges and cartridge connectors, but not a pump. An infusion systemmay include cartridge connectors and an infusion pump, but notmedicament cartridges. An infusion system may include infusionconnectors, a lumen assembly, cartridge connectors, an infusion pump,but not medicament cartridges or an infusion set. A blood glucosecontrol system can operate in conjunction with an infusion system toinfuse one or more medicaments, including at least one blood glucosecontrol agent, into a subject. Any feature, structure, component,material, step, or method that is described and/or illustrated in anyembodiment in this specification can be used with or instead of anyfeature, structure, component, material, step, or method that isdescribed and/or illustrated in any other embodiment in thisspecification. Additionally, any feature, structure, component,material, step, or method that is described and/or illustrated in oneembodiment may be absent from another embodiment.

Some embodiments described herein pertain to medicament infusion systemsfor one or more medicaments and the components of such systems (e.g.,infusion pumps, medicament cartridges, cartridge connectors, lumenassemblies, infusion connectors, infusion sets, etc.). Some embodimentspertain to methods of manufacturing infusion systems and componentsthereof. Some embodiments pertain to methods of using any of theforegoing systems or components for infusing one or more medicaments(e.g., pharmaceutical, hormone, etc.) to a patient. As an exemplaryillustration, an infusion system may include an infusion pump, which caninclude one or more medicament cartridges or can have an integratedreservoir of medicament. An infusion system may include medicamentcartridges and cartridge connectors, but not a pump. An infusion systemmay include cartridge connectors and an infusion pump, but notmedicament cartridges. An infusion system may include infusionconnectors, a lumen assembly, cartridge connectors, an infusion pump,but not medicament cartridges or an infusion set. A glucose levelcontrol system can operate in conjunction with an infusion system toinfuse one or more medicaments, including at least one glucose controlagent, into a subject. Any feature, structure, component, material,step, or method that is described and/or illustrated in any embodimentin this specification can be used with or instead of any feature,structure, component, material, step, or method that is described and/orillustrated in any other embodiment in this specification. Additionally,any feature, structure, component, material, step, or method that isdescribed and/or illustrated in one embodiment may be absent fromanother embodiment.

Further, certain embodiments disclosed herein relate to a glucose levelcontrol system that is capable of supporting different operating modesassociated with different adaptation ranges used to generate dosecontrol signals for delivering medicament to a subject. The differentadaptation ranges may be associated with a value or a change in value ofone or more control parameters used by a control algorithm that controlsthe administering of medicament to a subject. In some non-limitingexamples, the control parameter may be associated with the quantity ofmedicament, a delivery rate of medicament, a step-size or graduationused to modify the quantity of medicament between administrations of themedicament, a timing of supplying medicament to the subject, a glucoseabsorption rate, a time until the concentration of insulin in bloodplasma for a subject reaches half of the maximum concentration, a timeuntil the concentration of insulin in blood plasma for a subject reachesa maximum concentration, or any other control parameter that can impacta timing or quantity of medicament (e.g., insulin or counter-regulatoryagent) supplied or administered to a subject.

Advantageously, in certain embodiments, supporting different operatingmodes enables a user (e.g., a healthcare provider, parent, guardian, thesubject receiving treatment, etc.) to modify the operating mode of anambulatory medicament device. In some cases, the operating mode may bemodified automatically. Moreover, modifying the operating mode enablesdifferent dosing modes to be supported. Advantageously, supportingdifferent dosing modes enables an ambulatory medicament device to beused by different types of subjects, and/or a subject under differentconditions (e.g., when exercising, before, during, or after puberty,under different health conditions, etc.).

Some embodiments described herein pertain to medicament infusion systemsfor one or more medicaments and the components of such systems (e.g.,infusion pumps, medicament cartridges, cartridge connectors, lumenassemblies, infusion connectors, infusion sets, etc.). Some embodimentspertain to methods of manufacturing infusion systems and componentsthereof. Some embodiments pertain to methods of using any of theforegoing systems or components for infusing one or more medicaments(e.g., pharmaceutical, hormone, etc.) to a subject. As an exemplaryillustration, an infusion system may include an infusion pump, which caninclude one or more medicament cartridges or can have an integratedreservoir of medicament. An infusion system may include medicamentcartridges and cartridge connectors, but not a pump. An infusion systemmay include cartridge connectors and an infusion pump, but notmedicament cartridges. An infusion system may include infusionconnectors, a lumen assembly, cartridge connectors, an infusion pump,but not medicament cartridges or an infusion set. A blood glucosecontrol system can operate in conjunction with an infusion system toinfuse one or more medicaments, including at least one blood glucosecontrol agent, into a subject. Any feature, structure, component,material, step, or method that is described and/or illustrated in anyembodiment in this specification can be used with or instead of anyfeature, structure, component, material, step, or method that isdescribed and/or illustrated in any other embodiment in thisspecification. Additionally, any feature, structure, component,material, step, or method that is described and/or illustrated in oneembodiment may be absent from another embodiment.

Some embodiments described herein pertain to medicament infusion systemsfor one or more medicaments. Some embodiments pertain to methods ofusing infusion systems for infusing one or more medicaments (e.g.,pharmaceutical, hormone, etc.) to a subject. Some embodiments pertain tomethods of managing access to one or more therapy settings of amedicament infusion system. As an exemplary illustration, an infusionsystem may include an infusion pump, which can include one or moremedicament cartridges or can have an integrated reservoir of medicament.An infusion system may include medicament cartridges and cartridgeconnectors, but not a pump. An infusion system may include cartridgeconnectors and an infusion pump, but not medicament cartridges. Aninfusion system may include infusion connectors, a lumen assembly,cartridge connectors, an infusion pump, but not medicament cartridges oran infusion set. A blood glucose control system can operate inconjunction with an infusion system to infuse one or more medicaments,including at least one blood glucose control agent, into a subject. Aninfusion system may include a user interface that allow modifying one ormore control parameters that control medicament delivery to a subject.An infusion system may include a wireless transceiver that allows datacommunication between the infusion system and one or more electronicdevices.

Any feature, structure, component, material, step, or method that isdescribed and/or illustrated in any embodiment in this specification canbe used with or instead of any feature, structure, component, material,step, or method that is described and/or illustrated in any otherembodiment in this specification. Additionally, any feature, structure,component, material, step, or method that is described and/orillustrated in one embodiment may be absent from another embodiment.

Blood Glucose Control System Overview

A blood glucose control system (BGCS) is used to control blood glucoselevel in a subject. Blood glucose control systems can include acontroller configured to generate dose control signals for one or moreglucose control agents that can be infused into the subject. Glucosecontrol agents include regulatory agents that tend to decrease bloodglucose level, such as insulin and insulin analogs, andcounter-regulatory agents that tend to increase blood glucose level,such as glucagon or dextrose. A blood glucose control system configuredto be used with two or more glucose control agents can generate a dosecontrol signal for each of the agents. In some embodiments, a bloodglucose control system can generate a dose control signal for an agenteven though the agent may not be available for dosing via a medicamentpump connected to the subject.

Glucose control agents can be delivered to a subject via subcutaneousinjection, via intravenous injection, or via another suitable deliverymethod. In the case of blood glucose control therapy via an ambulatorymedicament pump, subcutaneous injection is most common. An ambulatorymedicament pump 100 is a type of ambulatory medical device, which issometimes referred to herein as an ambulatory device, an ambulatorymedicament device, ambulatory medical device, a mobile ambulatorydevice, or an AMD. Ambulatory medical devices include ambulatorymedicament pumps and other devices configured to be carried by a subjectand to deliver therapy to the subject. It should be understood that oneor more of the embodiments described herein with respect to one AMD maybe applicable to one or more of the other AMDs described herein.

In some embodiments, the AMD can be a portable or wearable device (e.g.,an insulin or bi-hormonal medicament pump) that provides life-savingtreatment to a subject by delivering one or more medicaments (e.g.,insulin and/or glucagon) to a subject. Some AMDs may continuouslymonitor the health condition of a subject (e.g., blood glucose level)using a sensor (e.g., a blood glucose level sensor that can measurevalues corresponding to the blood glucose level) and deliver therapy(e.g., one or more medicaments) to the subject based on the condition ofthe subject. Certain ambulatory medicament devices may be worn bysubjects constantly (e.g., all day), or for a large portion of the day(e.g., during waking hours, during sleep hours, when not swimming, etc.)to enable continuous monitoring of the health condition of the subjectand to deliver medicament as. In some embodiments, an AMD may be anambulatory medicament device such as a medicament delivery pump. In someexamples, an AMD may be a device that provides therapy in the form ofelectrical stimulation based on a health condition of a subject (e.g.,heart rhythm or brain activity) determined using signals received fromone or more sensors (e.g., heartbeat monitor or electrodes monitoringactivity of the brain). An example of an electrical stimulation deviceis a cardiac pacemaker. A cardiac pacemaker generates electricalstimulation of the cardiac muscle to control heart rhythms. Anotherexample of an electrical stimulation device is a deep brain stimulatorto treat Parkinson's disease or movement disorders.

FIG. 1A-FIG. 1C show examples of blood glucose control systems thatprovide blood glucose control via an ambulatory medical device or AMD,such as a medicament pump connected to a subject. In FIG. 1A, the AMD100 (medicament pump) is connected to an infusion site 102 using aninfusion set 104. The AMD 100 (medicament pump) has integrated pumpcontrols 106 a that permit a user to view pump data and change therapysettings via user interaction with the pump controls 106 a. A glucoselevel sensor 110 generates a glucose level signal that is received bythe blood glucose control system.

In FIG. 1B, the medicament pump 100 communicates with an externalelectronic device 108 (such as, for example, a smartphone or anotherremote device) via a wireless data connection. At least some of the pumpcontrols 106 a and 106 b can be manipulated via user interaction withuser interface elements of the external electronic device 108. Theglucose level sensor 110 can also communicate with the AMD 100(medicament pump) via a wireless data connection.

In FIG. 1C, the AMD 100 (medicament pump) includes an integrated cannulathat inserts into the infusion site 102 without a separate infusion set.At least some of the pump controls 106 b can be manipulated via userinteraction with user interface elements of an external electronicdevice 108. In some instances, pump controls can be manipulated via userinteraction with user interface elements generated by a remote computingenvironment (not shown), such as, for example, a cloud computingservice, that connects to the AMD 100 (medicament pump) via a direct orindirect electronic data connection.

Glucose control systems typically include a user interface configured toprovide one or more of therapy information, glucose level information,and/or therapy control elements capable of changing therapy settings viauser interaction with interface controls. For example, the user canprovide an indication of the amount of the manual bolus of medicamentfrom an electronic device remote from the medicament pump. The userinterface can be implemented via an electronic device that includes adisplay and one or more buttons, switches, dials, capacitive touchinterfaces, or touchscreen interfaces. In some embodiments, at least aportion of the user interface is integrated with an ambulatorymedicament pump that can be tethered to a body of a subject via aninfusion set configured to facilitate subcutaneous injection of one ormore glucose control agents. In certain embodiments, at least a portionof the user interface is implemented via an electronic device separatefrom the ambulatory medicament pump, such as a smartphone. In someembodiments, to protect patient privacy, the device screen may include afilter configured to have a predetermined viewing angle range such thatinformation cannot be seen on the touchscreen when viewed from an angleoutside of the predetermined viewing angle range.

FIG. 2A-FIG. 2D illustrate block diagrams showing example configurationsof a glucose control system 200 a/200 b/200 c/200 d. As shown in FIG.2A, a glucose control system 200 a can include a controller 202 a havingan electronic processor 204 a and a memory 210 a that storesinstructions 208 a executable by the electronic or hardware processor204 a. The controller 202 a can include a touchscreen controller. Thecontroller 202 a and a pump 212 can be integrated into an ambulatorymedical device (AMD) 100. The AMD 100 can have one or more pumps 212.The pump 212 can be a regulatory agent pump and/or counter-regulatoryagent pump. The AMD 100 can have one or more pumps 212. The AMD 100 caninclude a transceiver or wireless electronic communications interface214 a for wireless digital data communications with external electronicdevices. When the instructions 208 a stored in memory 210 a are executedby the electronic processor 204 a, the controller 202 a can implement atleast a portion of a control algorithm that generates dose controlsignals for one or more glucose control agents based on time-varyingglucose levels of the subject (e.g., received from a glucose levelsensor 110 that is in communication with the AMD 100, e.g., a medicamentpump) and one or more control parameters. The dose control signals, whendelivered to the pump 212, result in dosing operations that control theblood glucose of a subject. The pump 212 may be controlled by a pumpcontroller. The pump controller receives the dose control signals andcontrols the operation of the pump 212 based on the received dosecontrol signals. In some embodiments the pump controller may beintegrated with the pump.

As shown in FIG. 2B, a glucose control system 200 b can operate at leastpartially via execution of instructions 208 b by an electronic orhardware processor 204 b of an external electronic device 108 separatefrom the AMD 100. The external electronic device 108 can include atransceiver 214 b capable of establishing a wireless digital dataconnection to the AMD 100, and a controller 202 b can implement at leasta portion of a control algorithm via execution of instructions 208 bstored in memory 210 b. When the instructions 208 b stored in memory 210b are executed by the electronic processor 204 b, the controller 202 bcan implement at least a portion of a control algorithm that generatesdose control signals for one or more glucose control agents based ontime-varying glucose levels of the subject and one or more controlparameters. The dose control signals, when delivered to the pump 212(e.g., pump controller of the pump 212), may result in dosing operationsthat control the blood glucose of a subject. In some embodiments, thedose control signals are transmitted from the device transceiver 214 bto the AMD transceiver 214 a over a short-range wireless data connection216. The AMD 100 may receive the dose control signals and pass them tothe pump 212 (e.g., pump controller of the pump 212) for dosingoperations.

As shown in FIG. 2C, a glucose control system 200 c can operate at leastpartially via execution of instructions 208 c on an electronic processoror hardware 204 c integrated with a remote computer or device 206, suchas, for example, a cloud service. When the instructions 208 c stored inmemory 210 c are executed by the electronic processor 204 c, thecontroller 202 c can implement at least a portion of a control algorithmthat generates dose control signals for one or more glucose controlagents based on time-varying glucose levels of the subject and one ormore control parameters. The dose control signals, when delivered to thepump 212, result in dosing operations that control the blood glucose ofa subject. In some embodiments, the dose control signals are transmittedfrom the remote computer WAN connection interface 220 c to the AMD WANconnection interface 220 a over an end-to-end wireless data connection218. The AMD 100 receives the dose control signals and passes them tothe pump 212 for dosing operations.

As shown in FIG. 2D, a glucose control system 200 d can have two or morecontrollers 202 a, 202 b, 202 c that cooperate to generate a dosecontrol signal for dosing operations by the pump 212. In some examples,any one or any combination of controllers 202 a, 202 b, 202 c caninclude the touchscreen controller. A remote computer 206 can transmitor receive data or instructions passed through a WAN connectioninterface 220 c via an end-to-end wireless data connection 218 to a WANconnection interface 220 b of an external electronic device 108. Theexternal electronic device 108 can transmit or receive data orinstructions passed through a transceiver 214 b via a short-rangewireless data connection 216 to a transceiver 214 a of an AMD 100. Insome embodiments, the electronic device can be omitted, and thecontrollers 202 a, 202 c of the AMD 100 and the remote computer 206cooperate to generate dose control signals that are passed to the pump212. In such embodiments, the AMD 100 may have its own WAN connectioninterface 220 a to support a direct end-to-end wireless data connectionto the remote computer 206.

As shown in FIG. 3, in some embodiments, the glucose control system 200a includes circuitry that implements an electronic communicationsinterface (ECI) 302 configured to send and receive electronic data fromone or more electronic devices. The ECI includes a sensor interface orglucose sensor interface 304 configured to receive a glucose levelsignal from a glucose level sensor 110 such as a continuous glucosemonitor (CGM). Some CGMs generate the glucose level signal at fixed orperiodic measurement intervals, such as five-minute intervals. Theglucose level sensor 110 can be operatively connected to a subject inorder to generate a glucose level signal that corresponds to a bloodglucose estimate or measurement of the subject. The glucose level signalcan be used by the controller 202 a to generate a dose control signal.The dose control signal can be provided to a pump 212 via a deliverydevice interface or pump interface 306. In some embodiments, the sensorinterface 304 connects to the glucose level sensor 110 via a short-rangewireless connection 308. In some embodiments, the pump interface 306connects to the pump 212 via a short-range wireless connection 310. Inother embodiments, the pump interface 306 connects to the pump 212 via alocal data bus, such as when the controller 202 a, the ECI 302, and thepump 212 are integrated into an AMD 100. In addition, the pump 212 maybe connected to a pump motor 312.

The controller can be configured to generate the dose control signalusing a control algorithm that generates at least one of a basal dose, acorrection dose, and/or a meal dose. Examples of control algorithms thatcan be used to generate these doses are disclosed in U.S. PatentApplication Publication Nos. 2008/0208113, 2013/0245547, 2016/0331898,and 2018/0220942 (referenced herein as the “Controller Disclosures”),the entire contents of which are incorporated by reference herein andmade a part of this specification. The correction dose can includeregulatory or counter-regulatory agent and can be generated using amodel-predictive control (MPC) algorithm such as the one disclosed inthe Controller Disclosures. The basal dose can include regulatory agentand can be generated using a basal control algorithm such as disclosedin the Controller Disclosures. The meal dose can include regulatoryagent and can be generated using a meal control algorithm such asdisclosed in the Controller Disclosures. Additional aspects andimprovements for at least some of these controllers are disclosedherein. The dose control signal can be transmitted to a pump interface306 via the ECI 302 or can be transmitted to the pump interface 306 viaan electrical conductor when the controller 202 a is integrated in thesame housing as the pump interface 306.

As shown in FIG. 4A, the ambulatory medicament pump 212 can include oneor more medicament cartridges or can have an integrated reservoir 408 ofmedicament. The reservoir 408 may be integrated with the pump 212. Amedicament stored in the reservoir 408 can be delivered to the subjectby operation of the pump 212. In various embodiments, the operation ofthe pump 212 can be controlled by a controller 400. As shown in FIG. 4A,the controller 400 can be configured to operate in “online mode” duringtime periods when the controller receives a glucose level signal 402from a glucose level sensor 110. In online mode, the control algorithmgenerates a dose control signal 404 that implements regular correctiondoses based on values of the glucose level signal 402 and controlparameters of the control algorithm. The pump 212 is configured todeliver at least correction doses and basal doses to the subject withoutsubstantial user intervention while the controller 400 remains in onlinemode.

As shown in FIG. 4B, the controller 400 can be configured to operate in“offline mode” during time periods when the controller does not receivea glucose level signal 402 from a sensor 110, at least during periodswhen the glucose level signal 402 is expected but not received. Inoffline mode, the control algorithm generates a dose control signal 404that implements correction doses in response to isolated glucosemeasurements 406 (such as, for example, measurements obtained from thesubject using glucose test strips) and based on control parameters ofthe control algorithm. The pump 212 is configured to deliver basal dosesto the subject without substantial user intervention and can delivercorrection doses to the subject in response to isolated glucosemeasurements 406 while the controller 400 remains in offline mode.

Example Ambulatory Medical Device (AMD)

In some embodiments, the ambulatory medicament device (AMD) can be aportable or wearable device (e.g., an insulin or bi-hormonal medicamentpump) such as an ambulatory medicament pump (AMP) that provideslife-saving treatment to a subject by delivering one or more medicaments(e.g., insulin and/or glucagon) to a subject. Some AMDs may continuouslymonitor the health condition of a subject (e.g., blood glucose level)using a sensor (e.g., a blood glucose level sensor that can measurevalues corresponding to the blood glucose level) and deliver therapysuch as one or more medicaments to the subject based on the healthcondition of the subject. For example, an ambulatory medicament pump(e.g., an insulin pump or a bi-hormonal pump) may monitor the bloodglucose level in a subject using a Continuous Glucose Monitor (CGM) andadjust the dose or frequency of the medicament delivery (e.g., insulinor glucagon) accordingly. Certain ambulatory medicament devices may beworn by subjects constantly (e.g., all day), or for a large portion ofthe day (e.g., during waking hours, during sleep hours, when notswimming, etc.) to enable continuous monitoring of the health conditionof the subject and to deliver medicament as desired. In someembodiments, the AMD may be an ambulatory medicament device such as amedicament delivery pump. In some examples, the AMD may be a device thatprovides therapy in the form of electrical stimulation based on a healthcondition of a subject (e.g., heart rhythm or brain activity) determinedusing signals received from one or more sensors (e.g., heartbeat monitoror electrodes monitoring activity of the brain).

FIG. 5A illustrates a three-dimensional (3D) view of an exampleambulatory medical device 500 (e.g., an ambulatory medicament deliverypump such as an insulin pump) including a housing 502 with a wake button506 and a touchscreen display 504. FIG. 5B is an illustration of a crosssectional view of the ambulatory medical device 500 shown in FIG. 5A. Inthis example, all the electronic modules 508 are included inside thehousing 502, for example, as a single integrated electronic board. Thewake button 506 may be any type of button (e.g., capacitive, inductive,resistive, mechanical) that registers an input generated by userinteraction with the wake button 506 to generate a wake signal. In someembodiments, the wake signal is generated by a sensor (e.g., a biometricsensor such as a fingerprint reader or a retinal scanner, an optical orRF proximity sensor, and the like). In various embodiments, the wakesignal may be generated by user interaction with the touch screendisplay 504 or with an alphanumeric pad (not shown).

The wake button 506 may be located at one edge of the AMD, morespecifically, at a lower surface of the AMD for the user to convenientlyinteract (e.g., touch or tap) while holding or carrying the AMD. In someembodiments, there may be more than one wake button 506.

In certain embodiments, a user may wake the AMD from a sleep state orunlock the AMD by interacting with the touch screen display 504 havingvia a wake interface. When the AMD is in a sleep state or otherstate/mode, the touchscreen controller may not receive user interactionor user interaction signals corresponding to user interaction (e.g., viaan accelerometer or other motion sensors). As discussed herein, motionor motion detection may include all types of user gesture control inputsdiscussed herein, including tapping the AMD (including on thetouchscreen), touching or other gesturing on the touchscreen of the AMD,shaking the AMD, moving of the AMD, or motioning proximate the AMD suchas handwaving or other body part moving near, proximate, or in front ofa motion sensor (e.g., a camera) of the AMD.

In certain cases, a single tap such as on the back of the AMD oranywhere on the AMD can correspond to wake touchscreen and/or snoozealarm control inputs as discussed. Other tapping for user gesturecontrol inputs can include multi-tap such as double or triple tappinganywhere on the AMD, including the back of the AMD can correspond towake AMD, unlock AMD, quick meal announcement (e.g., for bolusadministration), confirmation of control inputs (such as when AMD isunlocked), and/or alarm acknowledgement control inputs as discussedherein. In some cases, multi-location-tap for gesture control inputs canbe utilized for additional user gesture control inputs. For example, theAMD can generate a user interface with two dots on touchscreen; the twodots can be tapped or touched simultaneously, sequentially, or multi-tapto provide control inputs for various actions and functions as discussedherein. In some cases, the AMD can implement specific timing betweentaps or touches or other gesture controls to register the control inputsas valid. For example, there can be 100 to 600 milliseconds timingbetween taps. The timing between taps can be adjusted by the user.

In some embodiments, the user may wake the AMD by touching the wakebutton 506 as the wake interface. In some cases, the wake button 506 maybe incorporated into the alphanumeric pad. In some cases, the wakeinterface 3220 may be any one or more keys of the alphanumeric pad. Insome cases, the wake interface may be a capacitive button that detects achange in capacitance. In some cases, a wake interface may have acomputing component for interpreting and executing instructions from thesignal processing component. Thus, the wake interface can follow aprogram that is dictated by the signal processing component. In somecases, a wake interface can include one or more additional userinterfaces mentioned above that are configured to generate and provide awake input (or wake signal) to the CCM when detecting a pre-set userinteraction. Alternatively, or in addition, the wake interface can beany type of wake interface element of the AMD that a user can interactwith to wake at least a feature (e.g., a touchscreen interface) of theAMD. In some cases, the wake interface element can be a physical button(e.g., a push button, a slide button, etc.), a capacitive element, aresistive element, or an inductive element. In some cases, the wakeinterface element can be or can include a biometric element, such as afingerprint reader, an iris scanner, a face detection scanner, etc. Insome cases, the AMD may wake in response to detection of a particularmovement or motion. In some cases, the AMD may wake in response todetection of a particular movement or motion. For example, adetermination that the ambulatory medicament device is being moved witha particular motion or within a line of sight or a visual range of auser may cause the AMD to awaken or cause the AMD to awake thetouchscreen interface of the AMD. The AMD may determine that the AMD isbeing moved within a line of sight of the user based on the type ofmotion and/or the detection of a user's eyes via, for example, an irisscanner or a camera.

In some examples, a wake signal may be generated based on facialrecognition or other biometric indicia. In some examples, the wakesignal may be generated by a wireless signal such as a signal generatedby an RFID system or Bluetooth signals received from an electronicdevice or by detection of movement using one or more motion sensors suchas an accelerometer.

The wake button 506, if touched, pressed, or held for a certain periodof time, may generate a wake signal that activates the touchscreendisplay 504. In some examples, touches on the touchscreen display 504are not registered until the wake button activates the touchscreendisplay. In some such examples, the AMD remains locked from accepting atleast certain types of user interaction or settings modification until agesture (such as, for example, any of the gesture interactions describedwith reference to any of the embodiments disclosed herein) is receivedafter the touchscreen display 504 is activated by the wake button 506.

In some examples, after the touchscreen display 504 has been activatedby the wake signal, a passcode may be required to unlock the touchscreendisplay.

FIG. 6 illustrates different modules that may be included in an exampleambulatory medical device 600. In some examples, all these modules maybe integrated together inside a single housing (as shown in FIG. 5B). Insome other examples, one or more modules may be individual modulescontained in separate housings that communicate with the main unit via awired or wireless communication links (e.g., Bluetooth). The modulesincluded in the AMD may include a communication module 602, signalprocessing module 604, a therapy delivery module 606, a user interfacemodule 608, and a control and computing module 610.

The control and computing module 610 may include one or more processors614, a main memory 616, a storage 618 that may include one or morenon-transitory memories and an interface 612 that enables data andsignal communication among the components within the control andcomputing module 610 as well as communication between the control andcomputing module and all other modules of the AMD. The main memory andthe storage each may be divided into two or more memory locations orsegments. The main memory 616 may communicate with the other componentsof the control and computing module 610 as well as other modules throughthe interface 612. Instructions may be transmitted to the main memory(e.g., from the storage) and the processor 614 executes instructionsthat are communicated to the processor through the main memory 616. Thestorage 618 may store data while the control and computing module 610 ispowered or unpowered. The storage 618 may exchange data with the mainmemory directly or through the interface 612. The main memory 616 can beany type of memory that can store instructions and communicate them tothe processor 614 and receive executed instructions from the processor614. Types of main memory include but are not limited to random accessmemory (“RAM”) and read-only memory (“ROM”). The processor 614 may beany type of general-purpose central processing unit (“CPU”). In someembodiments, the control and computing module may include more than oneprocessor of any type including, but not limited to complex programmablelogic devices (“CPLDs”), field programmable gate arrays (“FPGAs”),application-specific integrated circuits (“ASICs”) or the like. Thestorage 618 can be any type of computer storage that can receive data,store data, and transmit data to the main memory 616 and possibly othermodules of AMD. Types of storage 618 that can be used in the control andcomputing module 610 include, but are not limited to, magnetic diskmemory, optical disk memory, flash memory and the like. The interface612 may include data transfer buses and electronic circuits configuredto support data exchange among different components within the controland computing module 610. In some examples, the interface 612 may alsosupport data and signal exchange among other modules as well as dataexchange between any of the modules and the control and computing module610.

The signal processing module 604 may include a plurality ofinterconnected electronic modules for signal conditioning and signalconversion (e.g., A-to-D and D-to-A conversion) configured to supportcommunication and data exchange between different modules. For example,the signal processing module 604 may convert an analog signal receivedfrom the communication module 602 and convert it to a digital signalthat can be transmitted to the control and computing module 610 (e.g.,via the interface 612). As another example, the signal processing modulemay receive a digital control signal from the control and computingmodule 610 and convert it to an analog signal that can be transmitted tothe therapy delivery module 606, for example, to control one or morepumps.

The therapy delivery module 606 may include one or more infusion pumpsconfigured to deliver one or more medicaments to a subject. Themedicaments may be stored in one or more medicament cartridges housed inthe therapy delivery module 606. In some examples, the therapy deliverymodule may include electronic and mechanical components configured tocontrol the infusion pumps based on the signals received from controland computing module 610 (e.g., via the signal processing module 604).

The user interface module 608 may include a display to show variousinformation about the AMD, medicament type and delivery schedule,software status, and the like. Graphic images and text may be shown byany display technology including, but not limited to OLED, LCD, ore-ink. In some embodiments, the AMD, may include a user interface (e.g.,an alphanumeric pad) that lets a user enter information or interact withthe AMD to modify the settings of the AMD, respond to request forcertain actions (i.e., installing a software) and the like. Thealphanumeric pad may include a multitude of keys with numerical,alphabetical, and symbol characters. Keys of the alphanumeric pad may becapacitive or mechanical. The user may be a subject receiving medicamentor therapy, or may be another user, such as a clinician or healthcareprovider, or a parent or guardian of the subject. In some otherembodiments, the AMD may include a touchscreen display that producesoutput and also accepts input enabling a two-way interaction between theuser and the AMD. The touchscreen display may be any input surface thatshows graphic images and text and also registers the position of toucheson the input surface. The touchscreen display may accept input viacapacitive touch, resistive touch, or other touch technology. The inputsurface of the touchscreen display can register the position of toucheson the surface. In some examples, the touchscreen display can registermultiple touches at once. In some embodiments, the alphanumeric pad isdisplayed on the touchscreen display. The touchscreen may present one ormore user-interface screens to a user enabling the user to modify one ormore therapy settings of the ambulatory medicament device.

The communication module 602, may include one or more wirelesstransceivers, one or more antennas and plurality of electronic modules.Each transceiver may be configured to receive or transmit differenttypes of signals based on different wireless standards via the antenna(e.g., an antenna chip). The transceiver may support communication usinga low power wide area network (LPWAN) communication standard. In someexamples, the transceiver may support communication with wide areanetworks such as a cellular network transceiver that enables 3G, 4G,4G-LTE, or 5G. Further, the transceiver may support communication via aNarrowband Long-Term Evolution (NB-LTE), a Narrowband Internet-of-Things(NB-IoT), or a Long-Term Evolution Machine Type Communication (LTE-MTC)communication connection with the wireless wide area network. In yetother cases, the transceiver may support Wi-Fi® communication. In someexamples, the transceiver may be capable of down-converting andup-converting a baseband or data signal from and to a carrier signal. Insome examples, the communication module may wirelessly exchange databetween other components of the ambulatory medical system (e.g., asensor), a mobile device (e.g., smart phone), a Wi-Fi network, WLAN, awireless router, a cellular tower, a Bluetooth device, and the like. Theantenna chip may be capable of sending and receiving various types ofwireless signals including, but not limited to, Bluetooth, LTE, or 3G.In some examples, the communication module may support directcommunication between the AMD and a server or a cloud network. In someother examples the AMD may communicate with an intermediary device(e.g., a smart phone). In some embodiments, the AMD may include an eSIMcard that stores all of the information necessary to identify andauthenticate a mobile subscriber. The eSIM card may allow the ambulatorydevice to transmit data on a very inexpensive IOT device basis. In otherembodiments, the ambulatory medical device may be configured to transmitdata in a narrowband communication protocol such as 2G or EDGE. Usingthe cellular connection, the ambulatory medical device may be pairedwith the mobile device at inception and permit real-time data access tothe ambulatory medical device by a healthcare provider. In certainimplementations, the ambulatory medical device may include a geolocationreceiver or transceiver, such as a global positioning system (GPS)receiver.

Example Operation of the AMD

In some embodiments, the AMD may continuously, periodically, orintermittently receive information about one or more parameters that arecorrelated with a health condition of a subject (e.g., glucose level,glucose trend, heart rate, body movement indicia, etc.). Thisinformation may be encoded to a signal provided to AMD by a subjectsensor 620 (e.g., a wearable sensor that measured an analyte in theinterstitial fluid) that is connected to the ambulatory medical device600 main unit via a wired or wireless link (e.g., Bluetooth). In somecases, the subject sensor 620 can be any sensor that generates a signalor status value associated with one or more physiological indicators (orparameters) of a subject (e.g., heart rate, blood pressure, bodytemperature, level of blood sugar, serum levels of various hormones orother analytes). In some such examples, the subject sensor can be acontinuous glucose monitoring sensor (CGS). In some examples, the signalsent by the sensor may be received by the communication module 602 andtransmitted to a signal processing module 604 that converts the signalto a machine-readable signal (e.g., a digital signal). The signalprocessed by the signal processing module 604 may be transmitted to thecontrol and computing module 610 where it is analyzed to determinewhether medicament should be delivered to the subject. If it isdetermined that medicament is needed, the control and computing modulethe volume of the medicament may calculate required dosage based on theinformation received from the subject sensor 620 and send a signal tothe therapy module (e.g., via the signal processing module) to initiatethe medicament delivery process to the subject.

All the procedures within the control and computing module 610 areexecuted by the processor 614 (or a plurality of processors) based oninstructions provided by one or more software applications installed inone of the memories (e.g., the main memory) of control and computingmodule 610. These procedures include, but are not limited to,determining the need for delivering medicament, determining the type ofmedicament and the required dose, determining the rate of deliveryduring a therapy session, providing information (e.g., device status,next delivery time, level of certain analytes in the subject's blood andthe like) via the user interface module 608, processing the informationreceived from a subject sensor 620 via the user interface module 608,and the like. In some embodiments, a first software application maycontrol the AMD and may be installed on the main memory 616 while asecond software application (e.g., different version) may be stored inthe storage 618. In some examples, the first and second softwareapplications may be both installed in the main memory 616 but indifferent locations or segments. In these examples, if needed, thecontrol of the device can be switched from the first softwareapplication to the second software application.

In some embodiments, the ambulatory medical device 600 may delivermultiple types of therapies that are selectable by a user or the controland computing module 610. For example, the ambulatory medical device 600may deliver the therapy of infusing insulin into a user and may alsodeliver the therapy of infusing glucagon into a user. In some examples,the user interface may include an option for the user to select aninfusion of insulin, glucagon, or both insulin and glucagon. In otherembodiments, other hormones, liquids, or therapies may be delivered. Insome examples, the software application executed by the control andcomputing module 610, may determine the type of hormone that needs to bedelivered, at least partly based on the information received from thesubject sensor 620.

Communication and Networking

FIG. 7 illustrates various methods and links that an ambulatory medicaldevice (e.g., the AMD 702) may use to establish a connection with a hostcomputing system 704 in order to obtain an application update. The hostcomputing system 704 may be a server 706 or a computing system within acloud-based computing system 708 or other networked computingenvironment. The host computing system 704 may be part of a data center(e.g., the data center of a health care provider).

To obtain the application update, the AMD 702 may establish a connection(e.g., using its communication module) with the host computing systemthrough an intermediary device 710, such as a desktop computer, a mobiledevice (e.g., a smart phone, a laptop, and the like). In some examples,the intermediary device 710 can be an electronic device of a user or thesubject (e.g., a computer in a clinic, a subject's home computer, asmartphone, etc.) that has obtained a copy of the application updatefrom the host computing system directly or via internet 714. In someother examples the AMD 702 may communicate with the host computingsystem 704 through a local area network 712 through a Wi-Fi connection.Alternatively, or in addition, the AMD 702 may establish a connection tothe host computing system 704 via a wide area network 716. Moreover, thecommunication connection established between the AMD 702 and the cloudcomputing service may be encrypted.

In some embodiments, the AMD 702 may establish a direct end-to-endconnection over a wide area network 716 (e.g., a cellular network) withthe host computing system 704. The method may include receiving a publickey from the AMD 702. The public key and a private key stored in thehost computing system 704 can be used to permit the host computingsystem 704 to decrypt data communications transmitted by the AMD 702. Insome implementations, establishing the direct end-to-end data connectionincludes receiving a device identifier associated with the AMD 702. Thedevice identifier may be a unique identifier specific to the AMD 702.Further, establishing the direct end-to-end data connection may includedetermining that the AMD 702 is permitted to communicate with thecomputing system based at least in part on the device identifier. Thedevice identifier may be initially provided to the networked-computingenvironment prior to provisioning of the AMD 702 to the subject. Forexample, the device identifier may be initially provided to thenetworked-computing environment as part of a manufacturing process formanufacturing the AMD 702. The device identifier may include or may bebased on one or more of an Internet Protocol (IP) address, a MediaAccess Control (MAC) address, a serial number, or a subject identifierof a subject that receives therapy from the AMD 702. In some cases, thesubject or a user establishes or initiates establishing the directend-to-end data connection with the computing system. In other cases,the direct end-to-end data connection may be initiated or establishedwithout action by the subject or the user. For example, the directend-to-end data connection may occur automatically at particular timesor when the AMD 702 is in particular locations. This automaticconnection may occur using information supplied to the AMD 702 at a timeof manufacture, shipment, sale, or prescription to the subject. In somecases, the wide area network may include, or may communicate with, theinternet 714.

In some embodiments, the ambulatory medical device (e.g., AMD 702) maybe configured to communicate via the wide local area network 712 duringmanufacture or prior to being provisioned to the subject. For example, amanufacturer can register the ambulatory medical device with a wirelesswide-area network provider (e.g., T-Mobile or Verizon) and provide anInternational Mobile Equipment Identity (IMEI) number or serial numberfor the ambulatory medical device to the network provider. Moreover, anyfees can be negotiated or paid between the manufacturer and the networkprovider or between the subject's health insurance and the networkprovider. Thus, the subject's ambulatory medical device may beconfigured to communicate via the network of the network providerwithout any action by the subject.

In some other examples, the ambulatory medical device may bepre-registered or authenticated with a computing network of the cloudservices provider as part of the manufacturing process or before theambulatory medical device is provided to the subject. This enables theambulatory medical device to communicate over the wide area network withthe computing system of the cloud services provider from day one withoutany or with minimal configuration by the subject. In some cases, a user,such as a healthcare provider may register or associate the ambulatorymedical device with the subject at the computing network of the cloudservices provider.

To enhance security, the ambulatory medical device may use a whitelistthat identifies via a unique identifier (e.g., via an IP address, a MACaddress, or a URL) permitted cloud servers or computing system of thecloud computing system. Further, the cloud computing service may have awhitelist that uses unique identifiers to specify ambulatory medicaldevices and/or other computing systems (e.g., remote display systems)that are permitted to communicate with the cloud computing system.

To enhance security, the ambulatory medical device may use a whitelistthat identifies via a unique identifier (e.g., via an IP address, a MACaddress, or a URL) permitted cloud servers or computing system of thecloud computing system. Further, the cloud computing service may have awhitelist that uses unique identifiers to specify ambulatory medicaldevices and/or other computing systems (e.g., remote display systems)that are permitted to communicate with the cloud computing system. Thewhitelist may be stored in a memory of the ambulatory medical device.Further, the whitelist may be configured during manufacture of theambulatory medical device. For example, the whitelist may be configuredwith connection information to establish communication with one or morecomputing systems of a networked-computing environment. Further, theambulatory medical device may be configured to execute the specificcomputer-executable instructions to at least obtain an address of thecomputing system from the whitelist and to establish a direct end-to-enddata connection to the computing system of the networked-computingenvironment via a wireless wide area network using the address.Moreover, the ambulatory medical device may be configured to execute thespecific computer-executable instructions to at least receive a publickey from the computing system of the networked-computing environment.

Software Update of Ambulatory Medical Device

It is often the case that a computer application is updated after it isreleased. In some cases, the application is updated to patch bugs orvulnerabilities. In other cases, the application is updated or replacedwith a new version to introduce new features or improve existingfeatures. Regardless of the reason, it is often the case that anapplication is shutdown or is not executing while the application isupdated. For most applications, there is minimal to no harm in shuttingdown or not executing an application while it is updated or otherwisereplaced. For example, it is inconsequential that a video game, wordprocessing, or edutainment application is not executing while it isupdated.

However, it can be inconvenient, harmful, or, in some cases,life-threatening to cause an application on an ambulatory medical deviceto cease executing while it is updated or replaced by a new version ofthe application. If a subject or subject that is receiving therapy fromthe ambulatory medical device enters a state where therapy is desired orneeded while an application or control software of the ambulatorymedical device is being updated or replaced, harm may occur to thesubject. For example, suppose the ambulatory medical device is aninsulin pump, such as those that may be used by a type-1 diabetic. Ifthe insulin pump becomes inoperative due to a software update processoccurring at a time when a subject's blood glucose level exceeds aset-point or target range, the user may not receive a necessary insulinbolus from the ambulatory medical device. Thus, it is desirable tomodify reduce or eliminate disruption to subject care or therapy whenupdating applications, such as control software, of an ambulatorymedical device.

In some embodiments, an ambulatory medical device includes acomputer-implemented method of updating an application executing on theambulatory medical device without interrupting, or while causing minimalinterruption, to therapy provided by the ambulatory medical device to asubject or subject. The method may generally be performed by a hardwareprocessor, (e.g., a controller, and the like), included in an ambulatorymedical device and based on a set of instructions that may be stored,for example, in a non-transitory memory of the AMD. The applicationupdate may be a new version of the application, a replacement orsubstitute application, or an application patch. In some examples, theapplication may be an older version of the application that has beenused by instances of the ambulatory medical device for more than athreshold period of time and has experienced less than a thresholdnumber of faults. The application update may be stored in one or morehost computing systems. The application update may be pushed to the hostcomputing systems by a company that manages or manufactured theambulatory medical device or other software company that is authorizedby the manufacturer or licensee of the device.

FIG. 8 is a flow diagram showing an example of a computer-implementedmethod that may be used by the AMD in order to detect and download anapplication update from a host computing system or other computerreadable media in which a copy of the application update is stored. Incertain aspects, an ambulatory medical device, such as a medicamentdelivery device or a medicament pump may receive an indication that anupdate is available for an application (block 802), such as controlsoftware or other software that controls or facilitates the operation ofthe ambulatory medical device. The software update may include a binaryexecutable file for various processors of the ambulatory medical device.In some embodiments, the indication may be a determination made by asoftware or hardware module included in an ambulatory medical device ofAMD. For example, the AMD may access a particular host computing system(e.g., using its communication module) to determine whether an update isavailable, based on set of update trigger conditions stored in a memoryof AMD. The set of update trigger conditions may be defined/changed by auser and/or received by AMD from a host computing system. For example, atrigger condition may push the AMD to periodically search for an updateat time intervals set by the user or received from a host computingsystem. Alternatively, or in addition, in response to a trigger (such asa user command, the replacement of medicament within the ambulatorymedical device, the connecting to a particular network, or theconnecting to a network using a particular communication transceiver(e.g., Wi-Fi) or the like), the ambulatory medical device may access aparticular host computing system to determine whether an update isavailable to an application installed on the AMD. The software to beupdated on the AMD may be currently executing on the ambulatory medicaldevice or may be executed in future.

In some embodiments, the indication may a query received from the hostcomputing system that may access the AMD to read and compare thesoftware versions and the hardware configuration (and warranty) todetermine the eligibility of the ambulatory medical device for asoftware upgrade. The serial number, the model number, and/or thesoftware version may be used to determine software upgrade eligibility.In some embodiments, the eligibility may be determined based on thegeoposition of the device and/or whether the device is connected to alocal area network (such as for example, a Wi-Fi network) or a wide areanetwork (such as, for example, a cellular network). In variousembodiments, the ambulatory medical device may have an antenna thatprovides the device with GPS, text or picture messaging, telephonecalling, and data transfer capabilities. Software update may be providedon a limited release with test groups of varying sizes, e.g., 1-100 or1-1000 or 1-10000. There may be a phase rollout of the software updates.In some embodiments, the AMD may respond to an upgrade eligibilityrequest with a version of the first software or a model identificationinformation of the ambulatory medical device or a manufacturing date ofthe ambulatory medical device.

If it is determined that an update is available to the applicationexecuting on the ambulatory medical device, the ambulatory medicaldevice may establish a connection 804 to a host computing system thathosts the update to the application. Such connection may be establishedvia one or more links or methods discussed above with reference to FIG.7.

Once a connection is established, at block 806, the ambulatory medicaldevice may download the application update or application update fromthe host computing system over the connection. In some examples, theambulatory medical device may download an image of the applicationupdate from the host computing system. While the application update isbeing downloaded, an existing version of the application on theambulatory medical device may continue to execute. Thus, there is littleor no interruption to therapy provided by the ambulatory medical devicewhile the application update is being obtained by the ambulatory medicaldevice.

Once the application update is obtained, the ambulatory medical device(e.g., using its control and computing module) may perform one or moreoperations to confirm that the application update was successfullydownloaded from the application host system and that the download wasnot corrupted 808. For example, the ambulatory medical device maycalculate a hash or checksum value from the downloaded applicationupdate. This hash or checksum value may be compared with one receivedfrom the application host system. If the calculated hash or checksumvalue matches the received hash or checksum value, then it may bedetermined that the download is both complete and not corrupt. Further,the ambulatory medical device may use the checksum, a tag, a payloadsize, or any other method to confirm that the download of theapplication update is complete and not corrupt. If it is determined thatthe download is corrupt 808, the AMD discards the corrupt copy anddownloads another copy of the update 806. If it is determined that thedownload is complete and not corrupt, the AMD may proceed to theinstallation step 810 wherein the application update may be installed onthe AMD without interrupting the ongoing or upcoming therapy sessions.

FIG. 9-FIG. 11 are flow diagrams illustrating examples ofcomputer-implemented methods that may be used by the AMD to install adownloaded application update without disrupting the therapy provided toa subject.

In the example method illustrated in FIG. 9, if it is verified that anuncorrupted copy of the update for an application is successfullydownloaded 902 (e.g., using the procedure described above with referenceto FIG. 8), the control and computing module 610 (CCM 610) of the AMDmay determine the amount of time required to install the applicationupdate 904 and wait for a trigger signal 906 to initiate installationprocess. In some examples, the CCM may notify to the user 908 through auser interface (e.g., a touchscreen display), that an update is readyfor installation. The notification may include the installation time andinformation about the update. In such examples, if a trigger is notreceived, CCM may send one or more notifications to the user indicatingthat a new update is ready for installation. In some examples, thetrigger may be the confirmation that the application was successfullydownloaded. Alternatively, or in addition, the trigger may be a usercommand received based on an interaction by a user or subject with auser interface that is part of or that communicates with the ambulatorymedical device.

The installation time may be determined by the CCM based on data ormetadata provided with the downloaded application update. For example,the application update may include a file (e.g., a text file orconfiguration file) that includes the install time. The installationtime may be determined by the manufacturer of the ambulatory medicaldevice or the publisher of the application update. For example, thedeveloper of the software update may average the install time acrossseveral test devices to determine the install time metadata that isprovided with the software update. General purpose computers have a widevariety of configurations and the performance of a general-purposecomputer may vary depending on the applications executing at aparticular time. Thus, the determination of install time for anapplication based on the measurement of install time on a test device istypically unreliable. However, as an ambulatory medical device is oftena special-purpose device that is designed to perform a specific function(e.g., provide insulin to a subject), an install time determined duringtesting by a manufacturer may in many cases be a reliable determinationof install time on an ambulatory medical device of a subject.Alternatively, or in addition, to determining the install time based ontesting by a manufacturer, the install time of an application update maybe determined or estimated based on a size of the application update. Insome cases, the provided or estimated install time may include a buffer.In other words, an additional amount of time may be added to the installtime to account for variances in operating condition of the ambulatorymedical device or inaccuracies in the estimated install time.

If a trigger is received 906, the CCM may check for any ongoing therapysession 910. If the no therapy is currently being administered, the CCMdetermines the next therapy time 914 (or the time left until the nexttherapy session). If therapy is currently being administered theinstallation will be delayed 912 until the therapy session is compete.Once the current therapy session is complete, the CCM may determine thetime remaining until next therapy session 914 (e.g., during whichmedicament, such as insulin is delivered to a subject).

In some cases, the determination of the next time that therapy is to bedelivered may be an estimate based on historical delivery of therapy, apresent condition of the subject (e.g., when a glucose level is of asubject is at the center of a desired range, the next therapy deliverytime may be estimated to be further off than when the glucose level isat the edge of the desired range), and/or an indication provided by auser or subject (e.g., an indication that the user is planning to have ameal, to exercise, or to go to sleep). Alternatively, or in addition,the determination of the next time that therapy is to be delivered maybe based on a scheduled delivery of therapy (e.g., every 5 minutes orevery hour).

As previously described, it is desirable to prevent disruption totherapy during the application update process. Thus, after the nexttherapy time is determined 914, the estimated install time may becompared 916 to the determined or estimated next therapy delivery timeto determine whether the installation of the application update can becompleted before the next therapy delivery to the subject. If it isdetermined that the time left until the next therapy session issufficiently longer than the determined time for completing theinstallation, installation of the application updated may be initiated918. In some examples, the determined time to the next therapy sessionhas to be longer than the determined installation time by a thresholdvalue. Such threshold value may be different for different applicationupdates and/or the type of next therapy session. If it is determinedthat the application installation cannot be completed before the nexttherapy delivery (or the time left until the next therapy is not largerthan that estimated installation time by a threshold value), theinstallation of the application may be delayed, regardless of receipt ofthe trigger. In this case, the CCM may wait for the next therapy to becompleted and then determine a new therapy time 914. This process may berepeated until CCM determines that the update can be installed withoutinterrupting an expected or scheduled therapy by the ambulatory medicaldevice. In some examples, a new determination may be made beforecompletion of the next therapy, to determine whether installation may becompleted prior to a subsequent therapy time after the next therapytime.

In some cases, a time when the application can be installed withoutinterrupting therapy may not be identified. In some such cases, a user(e.g., a clinician or other medical provider, or a subject) may beprovided with an alert that an application update is available and/orthat the application update cannot be installed without interruptingtherapy. The user may be provided with an option as to whether to permitthe update and/or when to install the application update. The option mayinclude presenting the user with the estimated install time enabling theuser to schedule the application update at a time when interruptions totherapy may be minimal or when an alternative source of therapy (e.g.,injection therapy) can be utilized.

In some embodiments, once it is verified that an uncorrupted copy of theupdate for an application is successfully downloaded 902, the AMD'scontrol and computing module (CCM) may notify the user and wait for atrigger signal before determining the installation time. Once thetrigger has been received, the CCM initiates the installation process ofthe downloaded copy of the application update without interruptingtherapy provided by the ambulatory medical device to the subject. Insuch embodiments, the application update may be installed in a differentmemory location than the memory location where the original applicationis installed and executed.

FIG. 10 is flow diagram illustrating an example of acomputer-implemented method that may be used by the AMD in order toinstall a second application that is an update to a first applicationexecuting on the ambulatory medical device, without disrupting thetherapy provided to a subject. In this example, once the control andcomputing module 610 (CCM 610) of the AMD verifies that an uncorruptedcopy of the second application is successfully downloaded 1002 (e.g.,using the procedure described above with reference to FIG. 8), the CCMmay initiate the installation process of the second application 1004without interrupting the execution of the first application. The CCM mayconfirm 1006 the successful installation of the second application andwait for a trigger signal 1010 to initiate the execution of the secondapplication in place of the first application. In some examples, theinstallation of the second application may be confirmed by sending anotification the user 1008 via a user interface of the AMD. In someexamples, the CCM may determine the amount of time required forswitching the control of AMD to from the first application to the secondapplication. The notification may include information about the updateand the time required for switching between the applications. In someexamples, the trigger may be a user command received based on aninteraction by a user or subject with a user interface that is part ofor that communicates with the ambulatory medical device. In suchexamples, if a trigger is not received the AMD may send one or morenotifications to the user indicating that a new update is ready forinstallation. If a trigger is received, the CCM may check for anyongoing therapy session 1012. If the no therapy is currently beingadministered, the CCM determines the next therapy time 1016 (or the timeleft until the next therapy session). If therapy is currently beingadministered the installation will be delayed 1014 until the therapysession is compete. Once the current therapy session is complete, theCCM may determine the time remaining until next therapy session 1016.The estimated next therapy delivery time may be compared to a setthreshold time to determine whether the switching from the firstapplication to the second application can be performed withoutinterfering with the next therapy session. If it is determined that thetime left until the next therapy session is longer than the setthreshold time 1018, the execution of the second application will beinitiated and the execution of the first application will be halted1020. In some examples, the set threshold time may be determined by theCCM at least partly based on the time required to execute of the secondapplication and halt the first application. In some other examples, theset threshold time may be received from a host computing system.

In some embodiments, the performance of an application update may betested before switching control of the AMD to the application update.FIG. 11 illustrate an example method that may be used by suchembodiment. First the AMD verifies that an uncorrupted copy of theupdate for a first application is successfully downloaded 1102 (e.g.,using the procedure described above with reference to FIG. 8). Next theAMD may install 1104 and execute 1106 the downloaded copy of the secondapplication without interrupting the execution of the first applicationand therefore the therapy that might be provided by the ambulatorymedical device to the subject. In some examples, the second applicationupdate may be installed to a separate portion (e.g., a separateexecution space or separate memory) from the portion where the firstapplication is installed and is being executed. The Control andcomputing module 610 (CCM 610) of the AMD may determine a minimum set ofoperating conditions 1108 and then determine whether the minimum set ofoperating conditions are satisfied by the second application 1110. Insome cases, the minimum set of operating conditions may relate tomaintaining therapy provided by the ambulatory medical device to thesubject. If at block 1110 it is determined that the minimum set ofoperating conditions are not satisfied by the second application, theAMD may wait for an indication that a third application is available1112 and repeat the procedure described above to evaluate theperformance of the third application. If it is determined that theminimum set of operating conditions are satisfied by the secondapplication, the AMD may check for an ongoing therapy session 1114. Ifit is determined that currently no therapy is provided to a subject, CCMmay switch the control of the ambulatory medical device from the firstapplication to the second application 1118. If currently therapy isprovided to a subject, the CCM may wait until the therapy session iscompeted 1116 and then switch the control of the AMD from the firstapplication to the second application.

In some cases, the ambulatory medical device may be updated (ordowngraded) to add (or remove) features from the ambulatory medicaldevice. For example, the ambulatory medical device may initially provideonly insulin therapy. At some point in time, the ambulatory medicaldevice may be upgraded to include bi-hormonal control (e.g., to provideboth insulin therapy and counter-regulatory agent (e.g., Glucagon)therapy). The upgrade may be based on newly available features and/orbased on a decision by a user to purchase or otherwise obtain additionalfeatures. Similarly, a user may opt to downgrade therapy frombi-hormonal to insulin-only therapy. Alternatively, the upgrade ordowngrade may be made based on the availability of medicament. In someexamples, a first update can be a first application version including afirst feature set (e.g., providing insulin therapy) and a second updatecan be a second application version including a second feature set(e.g., provide both insulin therapy and Glucagon therapy). In some suchexamples the first feature set may include a subset of the secondfeature set. In some other examples, the first feature set may include apartially overlapping set of features with the second feature set.

In some examples a computer-implemented method that may be used by theAMD in order to detect, download and install an update to an applicationexecuting on the ambulatory medical device wherein the applicationincludes one of a first application version including a first featureset or a second application version including a second feature set. Insome examples, the first feature set may include partially overlappingset of features with the second feature set. In some other examples, thefirst feature set may include partially overlapping set of features withthe second feature set. The AMD may receive an indication ofavailability of the application update, download the application updateand verify that an uncorrupted image of the application update issuccessfully downloaded (e.g., using the procedure described above withreference to FIG. 8). Next, the control and computing module (CCM 610)of the AMD may initiate the installation process of the applicationupdate image without interrupting the execution of the application. Insome examples, the indication received by the AMD 802 (with reference toFIG. 8), may include information about application update being anupdate to the first application version or to the second applicationversion. In some such examples, the CCM 610 may determine the version ofthe application update and download the application update image basedon the determined version.

In some embodiments, any downloaded application update may be installedto a separate portion (e.g., a separate execution space or separatememory) from a currently executing version of the application. Onceinstallation of the application is complete and the application isverified as being successfully installed, the active version of theapplication can be switched. For example, control of the ambulatorymedical device can be provided to the updated application, thepreviously executing application can be ceased or halted. The oldapplication can then be removed or kept as backup. Determining when toswitch which version of the application is active may follow a similarprocess as previously described for identifying a next therapy deliverytime and selecting a time to switch active versions of the applicationwhen there will not be an interruption to the therapy provided by theambulatory medical device.

In some embodiments, the ambulatory medical device may be configured tostore multiple instances of an application (e.g., ambulatory medicaldevice control software). For example, the ambulatory medical device mayhave a current, or first, version of the application that it isinstalled in a first memory location (e.g., in the main memory 616) andis executing to, for example, control therapy provided by a subject.Further, the ambulatory medical device may include an updated, or secondversion of the application installed in a second memory location (e.g.,in the main memory 616). The update of the second version may have beendownloaded and installed (e.g., in a prior to detection of the fault).In such embodiments, when a fault is detected during execution of thefirst version of the application, the ambulatory medical device mayinitiate the execution of the second version of the application and thenswitch control of the AMD to the second version of the application tomaintain therapy to the subject.

In some examples, the second version of the application installed on theAMD may be a version older than the first version, or version that maynot have track a record of stability and reliability. FIG. 12 is a flowdiagram for such examples. Once an application-fault is detected duringexecution of the first version 1202, the control and computing module610 (CCM) of the AMD may switch the control of the AMD to the secondversion of the application 1204 while establishing a connection with ahost computing system configured to host a third update and download thethird update 1206. The third version of the application may be a newversion, a version prior to the first version, an update to the firstapplication that addresses the detected application-fault or an olderversion that satisfies the conditions to be classified as a “safeversion” (e.g., less than a threshold number or rate of faults over aminimum period of time). The second version (installed in the device)may control the AMD while the third version is being downloaded andinstalled 1208 without interrupting the therapy. Once the download ofthe third version is complete, the CCM may initiate the installationprocess of the downloaded copy of the third application and switchcontrol of the ambulatory medical device form the second application tothe third application 1210 without interrupting therapy provided by theambulatory medical device to the subject

In yet other embodiments, a “safe version” of the application may havebeen installed on the ambulatory medical device prior to detection of afault. The safe version of the application may include a version of theapplication that has been used by instances of the ambulatory medicaldevice for more than a threshold period of time and has experienced lessthan a threshold number of faults. For example, the safe version of theapplication may be a two-year old version of the application that hasdemonstrably had less than a threshold number of faults occur over theperiod of two years. This safe version of the application may have lessfeatures than the first or second version of the application. However,when a fault is detected during execution of the first or second versionof the application, the ambulatory medical device may switch control ofthe device to the safe version of the application to maintain therapy tothe subject.

In some cases, if there is an issue installing an updated version of theapplication, the ambulatory medical device may revert to the currentversion or a safe version installed on the AMD.

In some other examples, the AMD may be triggered to establish aconnection with the host computing system and search for the secondversion once a fault is detected during execution of the first version.In these examples, the ambulatory medical device may revert to the safeversion (installed in the device) while downloading and installing thesecond version without interrupting the therapy.

FIG. 13 is a flow diagram illustrating yet another example of a methodof responding to a fault detection by the AMD. In this example, once anapplication-fault is detected during execution of the first version ofan application 1302, the control and computing module 610 (CCM 610) ofthe AMD may look for a second version of the application 1304 in themain memory or the storage. If it is determined that the second versionhas been already downloaded, the CCM will determine 1306 whether thesecond version of the application is installed in a memory location andis ready to be executed. If it is determined that the second version ofthe application is installed, the control of the AMD will be switched tothe second version of the application 1308. With reference to block1306, if CCM determines that the second version exists in the memory,but it is not installed, it will switch the control of the AMD to a safeversion that may be already installed 1316 and then initiates theinstallation 1318 of the second version. Once the installation of thesecond version is complete, the CCM may switch control of the AMD fromthe safe version of the application to the second version of theapplication. In some embodiments, after the control of the AMD isswitched to the second version of the application, the CCM may searchfor a third version of the application 1310 that may be an update to thepreviously downloaded second version. If a third version is found, theCCM may download and install the third version 1312 and switch thecontrol of the AMD to the third version 1314. With reference to block1304, if the CCM cannot find a second version of the application in amemory or storage location, it will switch the control of the AMD to asafe version of the application 1320 that may be installed in a memorylocation (e.g., in the main memory or in the storage) and then searchfor a third version of the application 1310. If a third version isfound, the system may download and install the third version 1312 andswitch the control of the device to the third version 1314.

In some embodiments, when an application-fault of an applicationexecuting on the ambulatory medical device is detected, the AMD maytransmit an indication of the application-fault to the host computingsystem of a manufacturer or maintenance service of the ambulatorymedical device. In some other embodiments, the AMD may notify the userwhen an application-fault occurs through a user interface of the AMD oruser interface communicating with the AMD.

Direct Network-Connected Medical Device Communication and Remote Viewing

An ambulatory medical device, such as an ambulatory medicament device(e.g., blood glucose control system (e.g., an insulin pump or abi-hormonal pump that includes insulin and a counter-regulatory agent),a pacemaker, or any type of medical device that may be connected to asubject to provide therapy to the subject, can generate a significantamount of data related to therapy provided to a subject (therapy data).This therapy data may be useful for the subject, a healthcare provider,or other users (e.g., parent or guardian) to actively manage thesubject's health condition. For example, the therapy data may be usefulto determine whether a modification to therapy may be desirable or toconfirm that intended therapy is being delivered at the right time. Inother examples the data may be used to generate an alerts about thehealth condition of the subject when therapy data indicates thatimmediate attention is needed with regards to subject' health condition.

Various aspects of accessing the therapy data or other types of datastored in a memory of the AMD needs proper management in order toprovide uninterrupted, secure, and easy access to authorized users. Asdescribed above, the procedures and task performed by an AMD, includingthose associated with data transfer management, may be associated withcertain computer-executable instructions stored and executed by thecontrol and computing module 610 of the AMD 600. As such, different AMDconfigurations used for various data transfer management tasks, may beconfigurations of the control and computing module 610 of the AMD 600.

Accessing the data in the ambulatory medical device can be problematicin some cases. For example, accessing the data may require a user toconnect the ambulatory medical device to a computer to upload the data.This places a burden on the user to remember to connect the ambulatorymedical device. Further, during the period when the device is connectedto the computer, the subject may not be receiving therapy from theambulatory medical device. In some cases, the subject may not be capableof connecting the device to the computer (e.g., when the AMD is notwithin range of the local device) and may not have someone available toassist the subject. Thus, a direct end-to-end connection to a computingsystem that (e.g., computing system of a healthcare provider) can safelyshare data (e.g., therapy data) with authorized users may facilitatedata management and access.

FIG. 14 is a block diagram illustrating an example network configurationwherein the AMD 1402 is directly connected to a computing system 1406.In some cases, the AMD 1402 may receive data from one or moreenvironmental sensors 1404 and/or one or more medical sensors 1408(e.g., a glucose sensor operatively connected to a subject. Thecomputing system 1406 may be part of networked computing environment1412 (e.g., a data center, networked computing system), or cloud network1410 or cloud computing system of a cloud service provider. Thecomputing system may include one or more non-transitional memories andone or more hardware processors configured to execute thecomputer-executable instructions stored in one or more non-transitionalmemories. In some such examples, the procedures performed by thecomputing system may be associated with the execution of certaincomputer-executable instructions stored in a memory of the computingsystem by a hardware processor of the computing system.

In some examples, the direct end-to-end data connection may be supportedby one or more transceivers in AMD's communication module 602. Forexamples, a direct connection may be established between the AMD 1402and the computing system 1406 over a wide area network (e.g., a cellularnetwork) without using an intermediary system using various wirelessstandards and technologies (e.g., 4G, 5G and the like). In someexamples, the transceiver may support communication via communicationstandards, including but not limited to, low power wide area network(LPWAN), Narrowband Long-Term Evolution (NB-LTE), NarrowbandInternet-of-Things (NB-IoT), or Long-Term Evolution Machine TypeCommunication (LTE-MTC). In some cases, the transceiver is always on,and in other cases, the transceiver may be activated when a datatransfer is scheduled, requested, or activated. In some cases, thecapability of the ambulatory medical device 1402 to communicate with thecomputing system may be activated during manufacture or before providingthe device to a subject.

In some cases, the subject or a user establishes or initiatesestablishing the direct end-to-end data connection with the computingsystem. For example, the subject may interact with a user interface tocause the ambulatory medical device to communicate with the cloudcomputing service. In other cases, the direct end-to-end data connectionmay be initiated or established without action by the subject or theuser. For example, the direct end-to-end data connection may occurautomatically at particular times or when the ambulatory medical deviceis in particular locations. This automatic connection may occur usinginformation supplied to the ambulatory medical device at a time ofmanufacture, shipment, sale, or prescription to the subject. Further, insome cases, the ambulatory medical device can communicate with thecomputing system without having access to a Wi-Fi network or a localarea network (LAN). For example, the ambulatory medical device maycommunicate using a cellular or other wide area network. Further, insome cases, the interaction by the user with the ambulatory medicaldevice may be relatively minimal or simple compared to traditionalnetwork communication. For example, a user may push a single button(e.g., an “upload” button) to trigger establishing of a connection withthe cloud computing service and causing data to be provided from theambulatory medical device to the cloud computing service.

In some cases, the ambulatory medical device may be turned on and pairedwith the wireless wide area network (e.g., a cellular network) at thetime of manufacture, or prior to being provided to a subject. Further,the ambulatory medical device may be authenticated with thenetworked-computing environment as part of the manufacturing process

Further, establishing the direct end-to-end data connection may includedetermining that the ambulatory medical device is permitted tocommunicate with the computing system based at least in part on thedevice identifier.

In some implementations, establishing the direct end-to-end dataconnection may include determining that the ambulatory medical device ispermitted to communicate with the computing system based at least inpart on a device identifier associated with the ambulatory medicaldevice. The device identifier may be a unique identifier specific to theambulatory medical device. The device identifier may include or may bebased on one or more of an Internet Protocol (IP) address, a MediaAccess Control (MAC) address, a serial number, or a subject identifierof a subject that receives therapy from the ambulatory medical device.

Further, establishing the direct end-to-end data connection may includedetermining that the ambulatory medical device is permitted tocommunicate with the computing system based at least in part on thedevice identifier. The device identifier may be initially provided tothe networked-computing environment prior to provisioning of theambulatory medical device to the subject. For example, the deviceidentifier may be initially provided to the networked-computingenvironment as part of a manufacturing process for manufacturing theambulatory medical device. The request may include a device identifierassociated with the ambulatory medical device.

The ambulatory medical device may be configured to at least identify acomputing system 1406 of a networked computing environment 1412 based ona whitelist of one or more approved computing systems. The whitelist maybe stored in a memory of the AMD 1402 (e.g., a memory in the control andcomputing module of the AMD). Further, the whitelist may be configuredduring manufacture of the ambulatory medical device. For example, thewhitelist may be configured with connection information to establishcommunication with one or more computing systems of anetworked-computing environment. Further, the ambulatory medical devicemay be configured to at least obtain an address of the computing systemfrom the whitelist and to establish a direct end-to-end data connectionto the computing system of the networked-computing environment via awireless wide area network using the address. The whitelist may includeunique identifiers, such as MAC addresses or static IP addresses thatare associated with computing systems of the cloud services provider.

To enhance security, the ambulatory medical device may use a whitelistthat identifies via a unique identifier (e.g., via an IP address, a MACaddress, or a URL) permitted cloud servers or computing systems innetworked computing environment. Further, the cloud computing servicemay have a whitelist that uses unique identifiers to specify ambulatorymedical devices and/or other computing systems (e.g., remote displaysystems) that are permitted to communicate with the cloud computingsystem.

When the AMD communicates data over a network, there is a risk of a databreach. Thus, to improve security, all communication between theambulatory medical device and the computing may be based on a securedata transmission method. For example, the ambulatory medical device mayencrypt all data using an asymmetric key.

In some examples, the therapy data may be encrypted before beingtransferred to the computing system. In these examples, AMD may have apublic key and a private key stored in one of its memories permittingthe AMD to encrypt data communications transmitted by the ambulatorymedical device to the computing system. In these examples, AMD maytransmit the public key along with the therapy data to the computingsystem. The public key provided by the AMD and a private key stored onthe computing system may permit the computing system to decrypt the datareceived from the ambulatory medical device. In some such cases, thepublic key may timeout and a new public key may be obtained from theambulatory medical device to facilitate decrypting subsequentcommunications from the ambulatory medical device. In some cases, thepublic key may be associated with a time-to-live (TTL) value. In somesuch cases, the public key may timeout and a new public key may beobtained from the ambulatory medical device to facilitate decryptingsubsequent communications from the ambulatory medical device.

Moreover, the secure data transmission may include generating a sharedsecret based at least in part on the public key and the private key. Insome such cases, decrypting the encrypted data includes using the sharedsecret to decrypt the encrypted data. In some examples, shared secretmay be established using public key exchange algorithm (e.g.,Diffie-Hellman key exchange algorithm).

In some cases, the computing system may be configured to transfer thedata after receiving a request to transfer data stored on the ambulatorymedical device to the computing system over the direct end-to-end dataconnection via the wireless wide area network. Responsive to receivingthe request to transfer data stored on the ambulatory medical device tothe computing system, the computing system may be configured to receive,via the direct end-to-end data connection.

Once a connection is established and the therapy data is transferred tothe computing system, the computing system may analyze the therapy datareceived from the ambulatory medical device and generate a therapyreport. Further, the computing system may detect an alarm condition,based on therapy data analysis, and generate an alarm that may beprovided to the subject, authorized user (e.g., healthcare provider). Insome cases, the therapy data may trigger an automatic response by thecomputing system. For example, the AMD may determine that a medicamentor another disposable is running low based on the received data and mayautomatically reorder the medicament or the disposable.

In some cases, the computing system may periodically receive data fromthe ambulatory medical device based on a regular schedule.Alternatively, or in addition, the data may be received in response to acommand or when the ambulatory medical device determines it is within acertain location. For example, when the ambulatory medical devicedetermines it is within a subject's home or at a healthcare provider'soffice based on a local area network connection or based on ageolocation system (e.g., a global positioning system (GPS)). In someimplementations, additional encrypted data is received from theambulatory medical device on an intermittent basis. Alternatively, or inaddition, additional encrypted data is received from the ambulatorymedical device on a continuous basis for at least a time period. Theambulatory medical device may be configured to transmit data as it isgenerated, or shortly thereafter, (e.g., in real or near real-time(e.g., within a few millisecond, seconds, or minutes of the data beinggenerated)), or in bulk at specified periods of time. Transmitting thedata in bulk at particular time periods may extend battery life, but mayprovide for less up-to-date analysis. Data can be made availableon-demand by keeping the transceiver always on, but this may consumemore power. Thus, the scheduling of data transfer may be balanced basedon different considerations, such as: (1) power consumption and (2) needto share information with authorized users or systems.

In some cases, the computing system may be used as a backup for theambulatory medical device. For example, the ambulatory medical devicecan backup data to the computing system every night, when it ischarging, or when it is in proximity to home or a physician's office(e.g., when subject is in waiting room, the device may upload data thatthe physician can then access). Moreover, if the ambulatory medicaldevice is replaced (e.g., for a new model or to replace a damageddevice), the device can automatically synchronize with the computingsystem to obtain subject-specific configuration or therapy control data.

Therapy Data and Therapy Report

In some examples, the therapy data may include dose or dosage datacorresponding to one or more doses of medicament provided by theambulatory medical device to the subject. Further, the therapy data mayinclude subject data corresponding to a medical or physiological stateof the subject as determined by the ambulatory medical device.

In other examples, the data provided to computing system may include anytype of data that may be measured or obtained by the ambulatory medicaldevice and may include a record of therapy provided by the ambulatorymedical device. For example, the data may include a time that therapywas provided, an amount of medicament provided as part of the therapy, ameasure of one or more vital signs of the subject, a measure of bloodglucose levels at different times for the subject, a location of thesubject, and the like.

In some cases, the therapy data may be used to track the use ofdisposables, such as insulin or other medicament, or insulin pump sitekits. In some cases, the computing system may automatically order orreorder disposables at a particular time based on tracking the use ofthe disposable. Alternatively, or in addition, the reordering of thedisposables may be initiated or performed from the ambulatory medicaldevice (e.g., via a wireless wide area network or via a local connectionthrough a separate electronic device).

In some cases, the data transferred to the computing systems may includeoperation data corresponding to operation of the ambulatory medicaldevice. Alternatively, or in addition, the data may further includeerror data corresponding to an error in operation of the ambulatorymedical device.

In some examples, the data, therapy data and/or the therapy report maybe stored in a memory of the computing system and/or at a storage of thenetworked-computing environment.

In some cases, the method may include converting the therapy data fromone format to another format. For example, the method may includeconverting the therapy data from a format used to store and/or presentdata on ambulatory medical device to a format that can be stored orprocessed on the computing system. In some cases, the therapy data isconverted from a machine-readable format to a human-readable format. Thedata may be stored in a more easily interpreted format that can beunderstood by different types of users. For example, the data may bepresented in one format for a healthcare provider (e.g., sensorreadings), a simplified format for a subject or parent of a subject,other data formats for displaying data to different types of users.

In some examples, the therapy data collected from different AMDsassociated with plurality of subjects may be aggregated for a group ofsubjects based on their association with an institution or organization(e.g., a clinic, an insurance company, and the like)

In some other examples, a therapy report based at least in part on thetherapy data may be generated by the computing system. The therapyreport may include time-series therapy data relating to the therapydelivered by the ambulatory medical device over a particular timeperiod.

In some examples, the therapy report may be sent to AMD wherein thesubject can see the report via a user interface (e.g., a touchscreendisplay).

In some cases, the ambulatory device data and/or data generated by thecomputing system based on the ambulatory device data can be viewed on asecondary display system from the computing system. For example, aclinician or parent can access the data from their personal device. Thecommunication between the computing systems and the viewing device maybe encrypted. Moreover, permission for sharing of end user data with a‘follower’ (e.g., family member) or clinician may be granted orcontrolled by the end user (e.g., the subject or a guardian).

An association between a subject, a clinic, and/or an ambulatory medicaldevice may be performed by association of a device serial number of theambulatory medical device with the subject and/or clinic. Further, auser (e.g., a subject, clinician, or parent) can access therapeuticrecommendations through the cloud in case either the ambulatory medicaldevice (e.g., an insulin pump) or the CGM sensor fails to function.

With reference to FIG. 14, in some cases, the computing system may beconfigured to at least receive a request from one or more displaysystems 1414 that are separate from the networked computing environmentto access the therapy report, therapy data or other data received by orstored in the AMD. In some cases, the display system may be a computingsystem of a medical practitioner 1418 (e.g., such as a doctor, nurse, .. . ), a guardian of the subject 1420 (e.g., subject's parents), ahealth care service provider 1424 an authorized user 1422 (e.g., a userauthorized by the subject such as spouse, relative, friend, and thelike), or a device of the subject 1416 (e.g., cell phone, personalcomputer, tablet and the like).

In some examples, the display system can be a therapy data managementsystem that analyses a therapy data associated with a specific typehealth problem (e.g., data associated with managing diabetes) andprovides useful information to the subject or an authorized user tomonitor and manage the corresponding ailment.

The request may include an account identifier associated with a userthat generated the request. In some examples, the account identifier mayinclude a unique identifier associated with the subject. Alternatively,or in addition, the account identifier includes a unique identifierassociated with a user that is authorized to access the therapy report.The user may or may not be the subject. In some aspects of the presentdisclosure, the method may further include associating the therapy datawith the account identifier at a storage of the networked-computingenvironment. Further, the computing system may be configured todetermine whether an account associated with the account identifier ispermitted to view the therapy report. In some examples, accountpermissions may be granted and/or modified by the subject. For example,the subject can access an account at a networked computing environment1412, for example, a cloud service provider associated with the subject,and provide one or more identifiers associated with one or more otherusers to give them permission to access the subject's therapy data orreport stored on the computing system.

Responsive to determining that the account is permitted to view thetherapy report, the hardware processor may be configured to transmit thetherapy report to the display system over an encrypted communicationchannel.

In some cases, the method may include receiving an identity oridentification information of one or more users that are authorized toaccess therapy data stored at the networked-computing environment. Forexample, a user or subject may authorize a clinician or other healthcareprovider, a parent or guardian, or other users that the subject desiresto have access to the therapy data. The identity information of the oneor more users may include any type of information that may identify theuser or enable the user to be authenticated. For example, the identityinformation may include a name, unique identifier (e.g., social securitynumber), an email, an address, a phone number, account information forthe user at the networked-computing environment, or any otheridentifying information.

FIG. 15 is a flow diagram that illustrates an example method that may beused by computing system 1406, to generate and share a therapy reportbased on encrypted therapy data received from an AMD 1402. In someexamples, the AMD 1402 may generate the encrypted therapy data using apublic key and a private key. The method may include establishing adirect end-to-end data connection 1502 to an ambulatory medical device,for example, via a wireless wide area network (WAN) using a NarrowbandLong-Term Evolution (NB-LTE) transceiver included in the AMD 1402. Oncea direct end-to-end data connection between the AMD 1402 and thecomputing system 1406 is established, the computing system may receive apublic key 1504 (e.g., associated with encrypted data), from the AMD1402 over the established connection. Next, the computing system mayreceive a request from the AMD 1506 to transfer data (e.g., therapydata) stored on the AMD 1402 to the computing system 1406 over thedirect end-to-end data connection. In some examples, the computingsystem 1406 may use the device ID associated with the AMD 1402 todetermine whether the AMD 1402 is authorized to transfer data to thecomputing system 1508. If, based on the device ID, it is determined thatthe AMD 1402 is authorized to transfer data to the computing system, theencrypted therapy data may be transferred 1512 to the computing system.If, based on the device ID, it is determined that the AMD 1402 is notauthorized to transfer data to the computing system, the request may bedenied 1510. The computing system may decrypt the encrypted therapy data1514 using a private key (e.g., stored in a memory of the computingsystem) and a public key received from the AMD 1402. In some examples,the therapy data may be used to generate a therapy report 1516. In someexamples, the decrypted therapy data and/or therapy report may be storedin a memory of the computing system 1406.

The example method may further include receiving a request from adisplay system 1414 that is separate from the networked computingenvironment, to access the therapy report 1518. The request may includean account identifier associated with a user that generated the request.The method may include determining using the account identifier todetermine whether the account associated with the account identifier ispermitted to view the therapy report 1520. In the computing systemdetermines that the account associated with the received accountidentifier does not have the required permission, the request will bedenied 1524. Responsive to determining that the account is permitted toview the therapy report, the method may include transmitting the therapyreport to the display system 1522 over an encrypted communicationchannel.

In certain implementations, the method may further include determiningthat the therapy data or other data received from the AMD satisfy analert threshold condition. In these implementations, when the computingsystem determines that the therapy data or other data received from theAMD satisfy an alert threshold condition, the computing system may sendan alert to one or more display systems designated to receive alertsfrom the computing system.

In some examples, alert threshold condition may be associated with thehealth condition of the subject. For example, alert threshold conditionmay include subject's blood sugar level is above or below a set value(hyperglycemia or hypoglycemia). In some other examples the alertthreshold condition may be associated with the operation of the AMD. Forexample, alert threshold condition may include the rate of therapy(e.g., the rate at which insulin is provided to a subject) being aboveor below a set value.

In some other examples, alert threshold condition may be associated withthe temporal behavior of therapy data over a period of time. Forexample, the alert threshold condition may include the fluctuations orvariations of the subject's blood sugar level being above a set value.

In some examples, the alert threshold condition may be defined or set byhealth provider. In some such examples, the health provider may changeone or more alert threshold conditions based on the health condition ofthe subject.

FIG. 16 is block diagram, illustrating an example network and data flowconfiguration where an AMD 1602, which is directly connected to acomputing system 1606 (e.g., computing system within a cloud network1610), may generate and send alerts 1616 (e.g., alert messages, alertsignals, and the like) upon determining that data 1612 received from theAMD satisfies a threshold condition. The computing system 1606 may bepart of networked computing environment 1614 (e.g., a data center,networked computing system), or cloud network 1610 or cloud computingsystem of a cloud service provider. The computing system may include oneor more non-transitional memories and one or more hardware processorsconfigured to execute the computer-executable instructions stored in oneor more non-transitional memories. The AMD may receive data from one ormore medical sensors 1608 (e.g., analyte sensor, temperature sensor,heartbeat sensor, and the like) and/or one or more environmental sensors(e.g., geolocation receiver, motions sensor, accelerometer, and thelike). These sensors may be included in the AMD unit or may be connectedto the AMD via a wired or wireless link.

In some cases, the display systems receiving the alert 1620, may bedisplay systems that have already received therapy reports from thecomputing system 1606. In other examples, a group of display systems maybe selected and authorized by the subject, who is receiving therapy fromthe AMD, to receive alerts 1620. The display systems that may receivealerts 1620 from the AMD may include: a medical practitioner 1624 (e.g.,such as a doctor, nurse, etc.), a guardian of the subject 1626 (e.g.,subject's parents), an emergency service provider 1628, an authorizeduser 1630 (e.g., a user authorized by the subject such as spouse,relative, friend, and the like), a health care healthcare provider 1632,or a device of a subject 1622 (e.g., cell phone, personal computer,tablet and the like). In some examples, when it is determined thatreceived data 1612 the AMD satisfies a threshold condition, in additionto sending a alerts to one or more display systems 1618, the computingsystem 1606 may send an alert 1616 to the AMD 1602.

In some examples, the AMD 1602 may be configured to establish aconnection to support continuous data transfer to the computing system1606 for a given period of time (e.g., provided to the AMD by thesubject), in order to capture any data that is generated over thatperiod and satisfies an alert threshold condition. For example, thesubject may request a continuous connection between AMD and thecomputing system when going for hike alone to make sure that if his/herhealth condition deteriorate during the hike, an alert is sent toauthorized display systems.

In some examples, a geolocation sensor (e.g., a Global PositioningSystem (GPS) receiver) and/or a proximity sensor can be used to enablelocation-activated features such as automatic upload of data at certainlocations.

In some cases, the ambulatory medical device may include or be connectedto an accelerometer or a geolocation system. This velocity of theambulatory medical device may be determined based at least in part onthe accelerometer or geolocation system. Using the data obtained 1612from the ambulatory medical device 1602 including the location and/orvelocity information, the computing system 1606 can provide intelligentalerts. For example, if the data indicates that a user is travelling ata high rate of speed (e.g., likely in a car) and the user's bloodglucose level is low (e.g., below 55 mg/dl), the computing system mayautomatically alert emergency service provider 1628 that a subject is atrisk of hypoglycemia and may be driving. Further, the computing systemcan provide a location of the subject to the emergency service provider1628.

In some examples, the computing system can generate alerts based on atrend of the aggregated therapy data or based on therapy data that is anoutlier to the aggregate therapy data or an outlier to a time-basedaverage of the therapy data.

Further, the geolocation sensor and/or a motion sensor (e.g., anaccelerometer) can be used to detect velocity of a subject to enableintelligent motion-sensitive alerts. For example, if the subject ismoving at 60 mph and experiences low blood glucose, the system mayenable a set of driving alerts and schedule possibly therapy in thefuture. The driving alerts may inform the subject to pull overimmediately due to a risk of a hypoglycemic event. Further, an emergencyresponder may be informed of a subject location using based oninformation obtained from the geolocation sensor. If the subject ismoving at 6-7 mph, exercise alerts may be enabled to, for example, alertthe user to pause exercising and attend to low blood sugar. If thesubject hasn't moved for 3 hours and has low blood sugar, the system canenable automatic notification to and emergency service provider 1628.Further, a determination of the subject's motion can be used toautomatically adjust setpoint (e.g., raise setpoint during exercise).The activity level of the subject can be sensed and use to improvealerts and therapy.

Additionally, the cloud server can send a text message or call to afollower's and/or end user's phone or smart device in case the therapydata satisfies an alert threshold. These messages may be provided fromthe cloud computing system to a third-party device in case roaming ordisabling of the data plan on the ambulatory medical device occurs(e.g., no TCP/IP available). Further, the cloud computing service maysend a text message or call 911 in case of a detected emergency. Thecloud server can track, for example, via GPS, the end user's most recentlocation and share that information with a follower and/or emergencypersonnel. Moreover, the cloud computing system may enable an end userto order and re-order medical supplies directly from the viewing device.

Moreover, the computing system can generate notifications (e.g.,generate a message when there is a risk of hypoglycemia). Further, moredetailed processing in the cloud can result in improved recommendations(e.g., Tmax, setpoint, or other control parameters)

FIG. 17 is a flow diagram illustrating an example method that may beused by computing system 1606, to generate and send alerts (e.g., alertmessages, alert signals, and the like) to one or more authorized devicesand to the AMD. The method may include establishing a direct end-to-enddata connection 1702 to an ambulatory medical device, for example, via awireless wide area network (WAN) using a Narrowband Long-Term Evolution(NB-LTE) transceiver included in the AMD 1602. In some examples, thedirect end-to-end connection may be established for a given period oftime set by the subject or an authorized user (e.g., a guardian of thesubject). Once a direct end-to-end data connection between the AMD 1602and the computing system 1606 is established, the computing system mayreceive a public key 1704, from the AMD 1602 over the establishedconnection. Next, at block 1706, the computing system may receive arequest from the AMD 1602 to transfer data (e.g., therapy data, medicalsensor data or environmental sensor data) generated by the AMD 1602 tothe computing system 1606 over the direct end-to-end data connection. Insome cases, the request may include a time period during which AMDcontinuously transmits any data generated by the AMD 1602 or obtainedfrom one or more sensors (e.g., environmental sensors 1604 or medicalsensors 1608), to the computing system 1606. In some such cases, thetime period for continuous data transfer from the AMD 1602 to thecomputing system 1606, may be provided by the subject or a guardian ofthe subject to the AMD. At the decision block 1708, the computing system1606 may use the device ID associated with the AMD 1602 to determinewhether the AMD 1602 is authorized to transfer data to the computingsystem 1606. If the computing system 1606 determines that the AMD 1602is authorized to transfer data to the computing system 1606 (e.g., basedon the device ID), at block 1712, the encrypted therapy data may betransferred to the computing system 1606. If, at the decision block 1708the computing system 1606 determines that the AMD 1602 is not authorizedto transfer data to the computing system, the process may move to block1710 and the request may be denied. At block 1714, the computing system1606 may decrypt the received data using a private key (e.g., stored ina memory of the computing system 1606) and a public key received fromthe AMD 1602. At the decision block 1716 the computing system 1606 maydetermine whether the received data (e.g., therapy data, medical sensordata or the environmental sensor data), satisfies a threshold condition.In some cases, the threshold condition may be provided to the AMD by thesubject or an authorized user (e.g., a guardian of the subject). In someother examples, the threshold condition may be provided by a healthcareprovider. In some such examples, the threshold condition may be storedin a memory of the AMD. If at the decision block 1716 the computingsystem 1606 determines that the data satisfies a threshold condition, analert may be generated and sent 1718 to one or more display systems 1618that are authorized (e.g., by the subject or a guardian of the subject)to receive alerts. In some examples, the subject or the guardian mayauthorize one or more display systems 1618 to receive alerts byproviding the account IDs of the one or more displays systems to thecomputing system 1606 or the networked computing environment 1614.

Preventing Inadvertent Therapy Changes

As described above, the ambulatory medicament device may include a userinterface (e.g., touchscreen interface or a non-touchscreen interface)that may present one or more user-interface screens to a user enablingthe user to modify one or more therapy settings of the ambulatorymedicament device, such as a quantity of medicament delivered when acondition is met or the condition that triggers the delivery ofmedicament to a subject. The user may be a subject receiving medicamentor therapy, or may be another user, such as a clinician or healthcareprovider, or a parent or guardian. For ambulatory medicament devicesthat include a user interface, there is a risk that a setting isaccidentally modified or is modified (intentionally or unintentionally)by a user that does not fully comprehend his or her action (e.g., achild or a user with a reduced mental capacity). Further, ambulatorymedicament devices may accidentally have settings modified byinadvertent interactions with a user interface, such as may occur whenan ambulatory medicament device is worn against the body of a subject.

This section relates to an ambulatory medicament device (AMD) to preventan inadvertent modification in medicament deliver, for example, in theevent of a setting of the AMD being accidentally modified by a user orinadvertent interactions with a user interface.

As mention above, in some embodiments the user may modify the control orconfiguration the AMD using a user interface. There is a possibilitythat the control or configuration of the AMD is accidentally modifiedthrough the user interface. For example, as the user may transport theambulatory medical device, there is a danger that the user willinadvertently activate input in the ambulatory medical device thatinitiates a therapy change input (e.g., by applying pressure on theambulatory medical device that may be placed in the jacket pocket of theuser).

With reference to FIG. 18, in some such embodiments, the control andcomputing module (CCM) of the AMD may include a set of therapy changeprocedures 1818 implemented to prevent therapy change inputs 1820 thatare inadvertent. The therapy change procedures 1818 may be implementedas instructions stored in a memory of CCM (e.g., the main memory 616)and executed by the processor 614. The therapy change input 1820,received from a user 1816, may be verified by the therapy changeprocedures 1818 before the ambulatory medical device 600 provides thetherapy change delivery 1804. All the user interactions with the userinterface module 1806 may be controlled and analyzed by the control andcomputing module 610 (CCM) via one or more therapy change procedures1818.

In these embodiments, the user 1816 may wake or unlock the AMD byinteracting with a wake interface 1810. The wake interface 1810 can beany of the additional user interfaces mentioned above, configured togenerate a wake input to the CCM when detecting a pre-set userinteraction.

The therapy change input 1820 can be an input provided by the user 1816to change a therapy that is currently being delivered to the user 1816.In some embodiments, the therapy change input 1820 may cause the insulinor glucagon infusion pump to start infusing an amount of insulin orglucagon into the user 1816. Alternatively, the therapy change input1820 may modify the rate of insulin or glucagon infusion into the user1816. The therapy change input 1820 may also cancel insulin or glucagoninfusion into the user 1816 from the insulin or glucagon infusion pump.

When a wake action is detected by the wake interface 1810, a wake inputis sent to the control and computing module 610 wherein it imitates awake control procedure 1826 that generates a wake signal to wake/unlockthe user interface (e.g., a touch screen display).

When in the wake and/or unlocked state, a user may interact with thetouchscreen display 1812, alphanumeric pad 1814 or other types of userinterfaces that may be included in the user interface module 1806, toobtain access to therapy change user interface.

The therapy change user interface may be activated by a first userinteraction with the user interface (e.g., touchscreen display 1812).When the first user interaction is detected, the user interface moduleuser interface module 1806 sends an input signal to the control andcomputing module 610 wherein it is analyzed by a therapy change controlprocedure 1828. If it is determined that the first user interactionsatisfies a set of predefined conditions, the therapy change controlprocedure 1828 generates a signal to the user interface module userinterface module 1806 to activate the therapy change user interface.

In some embodiments, the therapy change user interface may be limitedbased on the first user interaction. For example, the therapy changecontrol procedure 1828 may send one of two signals to the user interfacemodule user interface module 1806. The therapy change user interface maythen unlock one of two different therapy change user interfaces thatresult in different options of therapy change selections for the user1816. In an implementation of this example, a therapy change selectionto make a significant therapy change, such as dramatically increase therate of insulin or glucagon infusion rate, requires a first userinteraction that is different from the first user interaction that wouldbe required for an insulin or glucagon infusion at a normal orprescribed rate. In some examples, the first user interaction may be asimple interaction (e.g., a simple gesture) that unlocks a therapychange user interface with therapy change selections that are limited.Another first user interaction may be a complicated interaction (e.g., aseries of complex gestures) that unlocks a therapy change user interfacewith therapy change selections that have no limits. An example of thisimplementation may be useful for child users. The child user may performthe first gesture that is made up of a series of simple inputs to unlocktherapy change selections that are limited. An adult user may performthe first gesture that is made up of a series of complex inputs tounlock the therapy change user interface with therapy change selectionsthat have no limits.

Once activated, the therapy change user interface that may provide oneor more control or configuration elements that enable the user to modifythe control or configuration of the ambulatory medicament device. Thecontrol or configuration element may include any type of user interfacescreen on the touchscreen, or other type of user interface in thenon-touchscreen context, that enables or permits a user to change aconfiguration of the ambulatory medicament device. This change inconfiguration of the ambulatory medicament device may relate to a changein the therapy provided or in the detection of a triggering event thatcauses therapy (e.g., medicament) to be provided to a subject. Forexample, the change in configuration may include a selection between oneor more hormones that regulate blood sugar level (e.g., insulin orglucagon) of a user, an amount of the one or more hormones that regulateblood sugar level of the user.

In some cases, a change to the configuration of the ambulatorymedicament device is automatically and/or instantly recognized orimplemented by the ambulatory medicament device, and/or transmitted tothe ambulatory medicament device. In other cases, a confirmation of thechange may be required before the change is implemented by ortransmitted to the ambulatory medicament device.

This confirmation may be entered based on a second user interaction witha user interface (e.g., touchscreen display 1812). When the second userinteraction is detected, the user interface module user interface module1806 sends an input signal to the control and computing module 610wherein it is analyzed by a therapy change control procedure 1828. If itis determined that the second user interaction satisfies a set ofpredefined conditions, the therapy change control procedure 1828implements the change to the configuration of the AMD.

The first and/or second user interactions may include the selection ofan icon, a series of taps or inputs, one or more gestures (e.g., alinear swipe, an arcuate swipe, a circular swipe, or other simple orcomplex movement across the touchscreen), performing a pattern orsequence on the touchscreen (e.g., drawing an image), a multi-touch ormulti-input interaction, a combination of the foregoing, or any othertype of interaction with a touchscreen, or portion thereof. The seriesof inputs may be any combination of touch movements, touch points,numerical characters, alphabetical characters, and other symbols.Gesture interactions can be guided by visual indicia displayed orprinted on the AMD. In some embodiments, the visual indicia can includeanimations that suggest or guide user interactions with a touchscreen.For example, the first user interaction can include an arcuate swipearound at least a portion of a generally circular icon or logo. In someexamples, the first and/or second user interactions may include apredetermined sequence of numerical or alphabetical inputs. In someexamples, a series of multiple inputs, the range of parameters for aninput may be dependent on other inputs in the series. For example,required start position of a touch movement may be dependent on theposition of the previous touch movement. The time that the series ofinputs are entered may also be a part of the range of parameters. Forexample, a series of inputs may need to be entered in no less than 3seconds or more than 3 seconds, and no more than 15 seconds or less than15 seconds.

Further, one or more of the interactions may include interacting with asensor as an optical sensor (e.g., visible light or IR sensor),biometric sensor (e.g., a fingerprint or retinal scanner), a proximitysensor, a gyroscope, or a combination of accelerometer and gyroscope,and the like. Also, in an exemplary embodiment, the second userinteraction may be made through a wireless signal such as RFID orBluetooth. In some embodiments, the second user interaction may includereceiving a selection of an indicator box that correspond to eitherinsulin or glucagon and receiving a predetermined sequence of numericalinputs in order to deliver the therapy change selection.

The type of user interaction that unlocks the touchscreen, providesaccess to a configuration screen, and/or confirms a change to theconfiguration of the ambulatory medicament device may be the same or maydiffer.

In an exemplary embodiment, the system may have a time-out such that ifno interaction occurs for a set period of time, the user interface willturn off and the therapy change request process has to start again. Inone implementation of the time-out, if no interaction occurs for morethan 30 seconds after the system is waked/unlocked before the seconduser interaction is received by the user interface, the user interfacewill be deactivated.

Once the configuration change is confirmed, implemented, or transmitted,the ambulatory medicament device may begin operating with the changedconfiguration.

This operation may include triggering therapy based on the newconfiguration or providing therapy based on the new configuration. Forexample, the ambulatory medicament device may generate a dose controlsignal based at least in part on the modified configuration or controlparameter or may detect a trigger based at least in part on the modifiedconfiguration or control parameter that leads to the provisioning oftherapy.

With continued reference to FIG. 18, in some embodiments, the changesmade through the therapy change user interface are sent to CCM whereinthe therapy change control procedure 1828 in CCM transfers the changesto the device and subject monitoring procedure 1824. The device andsubject monitoring procedure 1824 may be implemented in the CCM 610 tomonitor the status of the AMD (e.g., therapy delivery configuration) andthe health condition of the user 1816 (or a subject). For example, thesubject monitoring procedure 1824 may receive information about atherapy change requested by a user 1816 through a user interface (atouchscreen display 1812 or alphanumeric pad 1814) or information aboutglucose level in subject's blood from the subject sensor 1808.Subsequently, the device and subject monitoring procedure 1824 maytransmit the information pertaining a health condition of the subjectand/or the AMD configuration, to the medicament dose control procedure1822. In some examples, the parameters in the medicament dose controlprocedure 1822 may be adjusted based on the changes and/or informationcaptured by the device and subject monitoring procedure 1824. Themedicament dose control procedure 1822, controls the medicament deliveryinterface 1802 by providing a medicament dose signal. The medicamentdoes control may be generated based on detected conditions orphysiological characteristics of the subject (e.g., provided by thereadings of the subject sensor 1808) and according to parameter valuesreceived from the therapy change control procedure 1828. The medicamentdelivery interface 1802 may provide a therapy change delivery to theuser according to the information received by device and subjectmonitoring procedure 1824.

In some examples, the dose control signals may be produced based on time(e.g., medicament may be delivered on a periodic basis), one or more acommand, indication that the subject is planning to engage or isengaging in a particular activity (e.g., eating a meal, exercising,sleeping, fasting, etc.), or any other factor that may relate to orcause the triggering of therapy (e.g., medicament delivery).

FIG. 19 is a flow diagram illustrating an example method that may beused by an AMD to allow a user to change the configuration of theambulatory medicament device using a touch screen user interface. Theuser may initiate the configuration change process by waking/unlockingthe touch screen using a wake action. Once the wake action is receivedby the wake interface (block 1902), the wake interface sends a wakeinput to CCM (block 1904). At block 1906, the wake procedure generates awake signal and at block 1908 that unlocks the touch screen (block1908). Next, in response to receiving a first gesture by the user (block1910), the therapy change user interface is unlocked (block 1912). Usingone or more therapy control or configuration elements provided in thetherapy change user interface, the user may change the therapyconfiguration (block 1914). The user may confirm the changes made, byproviding a second gesture on the touch screen 1916. Once theconfirmation is received (block 1916) the requested changes will beimplemented (block 1918), and the ambulatory medicament device may beginoperating with the changed configuration. In some examples, once theuser confirms the changes made, a dose control signal may be sent to themedicament delivery interface 1802 that triggers a therapy changedelivery to the subject.

In some cases, the ambulatory medicament device, or a control devicethat enables a user to modify a configuration of the ambulatorymedicament device, may have a timeout feature. The timeout feature maycause the ambulatory medicament device or the control device to enter asleep or locked state after a period of time of inactivity by the user.In some cases, the timeout feature may cause the ambulatory medicamentdevice or the control device to enter a sleep or locked state after aparticular period of time regardless of whether the user is interactingwith the ambulatory medicament device or control device. Thus, a usermay have a limited period of time to modify the configuration of theambulatory medicament device.

In some examples, the therapy change made by a user may trigger thedelivery of a medicament according to the therapy change received andconfirmed by a user. This therapy change delivery may occur after a settime from period from receiving the confirmation.

In some embodiments of the AMD, an alarm status indicator may bepresented to the user via the user interface. The alarm status indicatorcan be an alert message or an alert symbol. The alarm status indicatormay be related to a configuration change made by a user, a change in thestatus of the AMD not related to a user input, or the condition of thesubject (e.g., detected by the subject sensor).

FIG. 20A is an illustration of the touchscreen display 2000 of anexample AMD after the touch screen is waked/unlocked by a wake action ofa user and before the first user gesture is received. Even while thetouchscreen display is locked, the touchscreen display 2000 may displayany images, animations, text, or other graphics. The first gestureprompt 2006 displays to the user 1816 the input required to unlock thetherapy change user interface. Here, the first gesture prompt 2006 showsthe user 1816 that a touch movement that begins at the greater-thansymbol and moves right across the “Unlock” text is the acceptable firstgesture. In addition to the first gesture prompt, the refill status ofthe ambulatory medical device 600 is shown in a graphic representation2010. Here, the graphic representation 2010 shows that the insulincartridge in the ambulatory medical device 600 is almost full. A currentblood sugar level 2016 is shown at the top of the touchscreen display2000, which can inform the user 1816 of the need for a hormone thatregulates blood sugar levels. The touchscreen display 2000 also shows agraphic representation of a cartridge of glucagon 2024. The graphicrepresentation of an alarm 2030 in the touchscreen display 2000 showsthat an alert is set on the ambulatory medical device 600.

FIG. 20B is an illustration of an example touchscreen display 2038 thatmay prompt the user to enter a predetermined series of inputs for thefirst gesture or second gesture. In various embodiments, such as theembodiment shown in FIG. 20B, the touchscreen display 2038 may displaytouchable number keys 2040. In various embodiments, the touchscreendisplay 2038 prompts the user 1816 to enter the series of inputs thatcomplete the first gesture or second gesture. The text Enter Code 2042prompts the user 1816 to enter a predetermined or preselected numericalsequence as part of the first gesture or second gesture. The numericalsequence being typed by the user 1816 is displayed in field 2044 as itis entered as an aid to the user 1816. The input 2046 of the touchscreendisplay 2038 shows that a touch movement of a swipe right across thebottom of the screen is required to complete the predetermined series ofinputs for the first gesture or second gesture. A Bluetooth connectionsymbol 2048 shows that the ambulatory medical device 600 is paired orcan be paired to another electronic device.

FIG. 20C is an illustration of an example therapy change user interface(in this case a touchscreen display 2002). The touch screen display maythe user 1816 prompt to select a hormone that regulates blood sugarlevel. The touchscreen display 2002 presents the user 1816 with anoption to select between two hormones. The touchscreen display 2002 aidsthe user 1816 by showing the selected hormone 2008 for the user 1816.The selected hormone 2008 is “insulin Only”. The user 1816 is also giventhe options of selecting the hormone Glucagon Only button 2012 or bothInsulin & Glucagon button 2004 to regulate blood sugar level. Once theuser 1816 selects between the one or more hormones that regulate bloodsugar level. The Next button 2014 may be selected to complete thetherapy change selection or select more options. In one embodiment, toselect more options, the therapy change user interface prompts the user1816 to select an amount of the one or more hormones that regulate bloodsugar level of the user 1816. In other embodiments, the user 1816 may beprompted to select a blood sugar level and the ambulatory medical devicemay choose the hormone and the amount of the hormone.

FIG. 20D is an illustration of another therapy change user interface ona touchscreen display 2018. Here, the user 1816 is given a multitude ofoptions. One or more options in the therapy change user interface allowthe user 1816 to make a therapy change selection. Other options arerelated to the therapy change selection. A Deliver Hormone button 2036allows the user 1816 to select a therapy change that delivers a hormonethat regulates blood sugar to the user 1816. A Test Blood Sugar button2020 allows the user 1816 to test the blood sugar level of the user1816. A Generate Report button 2022 generates a document that reportsthe therapy changes that have been delivered to the user 1816. A RefillCartridge button 2026 allows the user 1816 to fill a cartridge in theambulatory medical device 600 with medicament. An Upload to Cloud button2032 allows the user 1816 to transmit therapy change information to acloud-based server. A Sound Control button 2028 allows the user 1816 tocontrol the sounds emitted by the ambulatory medical device 600. ASettings button 2034 allows the user 1816 to manipulate other settingsof the ambulatory medical device 600.

As mentioned above, in some embodiments of the AMD, an alarm statusindicator may be presented to the user via the user interface to alertthe user about a change made or occurred in the AMD configuration.

For example, with reference to FIG. 18, the user 1816 may provide atherapy change input 1820 using the user interface and based on theprocedure illustrated in FIG. 19. Once therapy change control procedure1828 implements the therapy change, the AMD may alert the user that atherapy change is implemented. The alert message or symbol may bepresented on a user interface (e.g., touch screen display) before and/orduring the therapy change delivery 1804. For example, alarm indicatormay inform the user 1816 that a therapy change is about to occur. Anynumber of details of the therapy change may be displayed as part of thealert message or symbol. In some cases, the alarm status indicator mayappear after the user unlocks or wakes the user interface using a wakeaction.

FIG. 21 is a flow diagram illustrating an example method that may beused by an AMD to generate an alarm status indicator. In someembodiments the device and subject monitoring procedure (excused withinCCM), may continuously monitor the status of the AMD (e.g., the userinterface, different modules of the AMD and the like) as well as thehealth condition of a subject (e.g., using various subject sensors suchas analyte sensors) 2102. Once a status information is received 2104,the device and subject monitoring procedure may determine whether thereceived status information satisfies an alarm condition 2106. If thereceived status information does not satisfy an alarm condition, nocation will be taken and device and subject monitoring procedurecontinuous monitoring the AMD and the subject. If it is determined thatthe received status information satisfies an alarm condition, the systemsearch for a wake signal 2108. If no wake signal is detected, thesystems wait for or determine a wake signal to be received 2110. Once awake signal is received via one or more user interfaces or sensors, theCCM may generate a display of a touchscreen lock screen interface 2112and display one or more alarm status indicators 2114, corresponding tothe detected alarm condition, on the lock screen.

In some embodiments, the AMD may allow the user to provide a therapychange and then cancel the therapy change. FIG. 22 is a flow diagramillustrating an example method that may be used to cancel a therapychange using a touchscreen interface. The user may unlock thetouchscreen display 2202 using a wake action and get access to a therapychange user interface 2204 (e.g., using a first gesture), where one ormore therapy control elements may be displayed. Next, an indication of amodification to a therapy control element may be received 2206 by theuser interface followed by a confirmation of the modification made 2208(e.g., a second gesture). In response to receiving an indication andconfirmation of a modification to a therapy control element, thecorresponding control parameter may be changes from a first setting to asecond setting 2210. In some examples, once the change is implemented2210, the user may decide to cancel it, for example, after realizingthat requested change is erroneous. In these examples the user mayprovide a third gesture 2212 on the touch screen. In response toreceiving the third gesture from the user interface the therapy changeprocedure may restore the modified control parameter to the firstsetting 2214. In some examples the third gesture may a restore gesture.In some cases, the restore gesture may be a swipe gesture. In someexamples the swipe gesture may be performed near or in a region of thetherapy change user interface that is occupied by the therapy controlelement. An example of a restore swipe gesture may be performed from astarting swipe position to an ending swipe position located closer to aleft edge of the touchscreen than the starting swipe position. In someembodiments, the restore gesture is received on a different userinterface screen than a therapy change user interface wherein one ormore therapy control element are provided. In various examples, therestore gesture is performed in the opposite direction from a therapychange confirmation gesture that confirms the modification to thetherapy control element.

In some examples, in order to cancel a therapy change request, therestore gesture has to be provided within a set time period after theconfirmation gesture is received by the user interface. In some suchexamples, during the set time period one or more dose control signalsmay be provided to the medicament delivery interface resulting in one ormore therapy change deliveries.

In some cases, the system may allow the user, to modify a therapy changebefore confirmation. In these cases, the user may modify a therapycontrol element for a second time to change the corresponding controlparameter from a second setting to a third setting.

In some examples, the third setting may be the same as the firstsetting. In some cases, the first setting or the third setting may be adefault setting. In some other cases, the first setting or the thirdsetting may be a restore setting.

FIG. 23A is an illustration of a touchscreen display 2300 alerting theuser that the delivery of one or more medicaments will occur. The alertmay be accompanied by sound or vibration effects. Here, the alertinforms the user 1816 a delivery of medicament will occur in 2 seconds2302. The touchscreen display 2300 is further allowing the user 1816 toperform a gesture to cancel the therapy change. The gesture to cancelthe delivery is a touch movement that starts at the less-than symbol2304 and swipes left across the “Cancel” text. In the embodiment shownin FIG. 23A, a single gesture by the user 1816 may cancel the therapychange. In an exemplary embodiment, input of the wake signal, the firstgesture, the therapy change selection, and the second gesture are allrequired to cancel a therapy that is being delivered.

In some examples, the user may be able to cancel a therapy changedelivery triggered based on therapy change made by the user. In theseexamples, the user may get access to the user interface using a wakeaction and provide a gesture to cancel the ongoing therapy correspondingto a therapy change delivery.

FIG. 23B is an illustration of a touchscreen display 2306 showing that amedicament is being delivered to the user 1816. The text Delivering 2308informs the user 1816 that a medicament is currently being delivered tothe user 1816. The progress bar 2310 is a graphic representation of theprogress of the delivery. In the example shown in FIG. 23B, the deliveryhas just started and the progress indicates that no medicament has beendelivered yet. The touchscreen display 2306 is allowing the user 1816 toperform a gesture to cancel the delivery, which includes interruptingand discontinuing the delivery if it had already begun but has not yetbeen completed. The gesture to cancel the delivery is a touch movementthat starts at the less-than symbol 2312 and swipes left across the“Cancel” text. In an exemplary embodiment that is shown in FIG. 23B, thetherapy change delivery 1804 may be canceled by an input by the user1816. The input to cancel a therapy change delivery 1804 may be anyinput such as a wake signal input or a series of touch inputs such as agesture.

Additional embodiments relating to interacting with an ambulatorymedicament device that can be combined with one or more embodiments ofthe present disclosure are described in U.S. Provisional Application No.62/874,950, which was filed on Jul. 16, 2019 and is titled “PREVENTINGINADVERTENT THERAPY CHANGES ON AN AMBULATORY MEDICAL DEVICE,” thedisclosure of which is hereby incorporated by reference in its entiretyherein for all purposes, and in U.S. Provisional Application No.62/874,954, which was filed on Jul. 16, 2019 and is titled “CAPACITIVETOUCH WAKE BUTTON FOR AN AMBULATORY MEDICAL DEVICE,” the disclosure ofwhich is hereby incorporated by reference in its entirety herein for allpurposes.

Automatic Resumption of Medicament Delivery Following Manual Suspension

In some cases, it may be desirable to suspend operation of theambulatory medicament device or to suspend at least the delivery ofmedicament by the ambulatory medicament device for a period of time. Forexample, it may be desirable to suspend an operation associated with thedelivery of medicament when the medicament reservoir or cartridge in theambulatory medicament device is empty or needs replacing. As anotherexample, it may be desirable to suspend delivery of medicament when theambulatory medicament device is removed or is being moved to anothersite on the subject. In yet another example, it may be desirable tosuspend delivery of the medicament when the subject is taking oringesting another medicament that may produce a contraindication withthe medicament provided by the ambulatory medicament device. In somecases, when a subject suspends the treatment delivered by a medicaldevice, the subject may forget to resume the treatment delivered by themedical device. In other cases, the health condition of the subject maydeteriorate during the suspension period requiring therapy deliveryprior to end of the suspension period. As such, there is a need for AMDsthat allows subjects to safely suspend treatment for temporary amountsof time.

In some embodiments, the AMD may support a therapy suspension andresumption procedure allowing a user to suspend all therapies or asubset of therapies for a period of time defined by the user as well asautomatic resumption of one or more therapies at the end of therequested suspension period or when a threshold condition is met (e.g.,a threshold condition associated with the health condition of thesubject).

In AMDs that support therapy suspension, inadvertent activation and/orresumption of therapy delivery can be dangerous (e.g., when the AMD isan insulin and/or glucagon infusion device). In some examples tomitigate this risk, the AMD may be configured to avoid inadvertentsuspension or resumption of therapies. For example, inadvertentactivations of suspensions of medicament delivery may be prevented byrequiring a user to perform gestures to activate suspension on theambulatory medical device. In some cases, the gestures may activate atherapy suspension when entered at a particular prompt to.

One particular application of the therapy suspension with automaticresumption feature in an AMD can be in the field of diabetes drugdelivery. For example, the may need the ability to suspend delivery ofinsulin during situations such as exercise, which has a blood glucoselowering effect. Suspension of insulin delivery can prevent a subjectfrom entering a hypoglycemic state (extreme low blood glucose), whichcarries severe complications. Once the therapy is suspended the usermany at the risk of entering a hyperglycemic state (high blood glucosethat may result in complications such as diabetic ketoacidosis orneurovascular complications) if the user forgets to reactivate the drugdelivery after exercise. Further, the subject's blood glucose level mayraise above or below a dangerous level during the period of exercise. Inthese situations, the automatic medicament delivery resumption mayimprove the health of the subject.

In certain cases, the AMD may suspend one or more therapy deliverieswhen the AMD receives an indication that therapy (e.g., delivery ofmedicament) is to be suspended. The indication that therapy is to besuspended may be a command from a user. Often the user is the subject,but the user may also include other users that may have a say orinterest in the care of the subject. For example, the user may be aclinician or other healthcare provider, or a parent or guardian.

In some examples, the indication that the therapy or medicament deliveryis to be suspended may be a command received via an interface of theambulatory medicament device or from another device that provides theuser with an interface to request that medicament delivery be suspended.For example, the device may be a smartwatch, smartphone, laptop ordesktop, or other control device that can communicate via a wired orwireless connection with the ambulatory medical device.

In some cases, the indication that the therapy or medicament delivery isto be suspended may be received from the ambulatory medicament deviceitself. For example, if the quantity of medicament available to theambulatory medicament device drops below a threshold (e.g., thecartridge or reservoir is empty or below a minimum dosage amount), asignal may be generated to suspend medicament delivery. In someembodiments, suspension of therapy occurs based on a loss of a sensorsignal, such as the loss of a glucose level signal.

FIG. 24 illustrates the interconnection among modules and proceduresinvolved in receiving, accepting and/or canceling a therapy suspensionrequest, in an example AMD. In some embodiments, a request forsuspending one or more therapies (e.g., delivery of one or moremedicament to the subject) can be made by a user 2414 by providing auser input 2418 (e.g., the start and stop time for therapy suspension,selecting the type of therapy that should be suspended, and the like),through a therapy suspension user interface provided by the userinterface module 2404. The therapy suspension user interface sends thesuspension request along with the corresponding information to CCMwherein the therapy suspension control procedure 2426 implemented inCCM, processes and sends a therapy suspension signal to the device andsubject monitoring procedure 2422. To prevent therapy suspension requestuser inputs 2418 that are inadvertent, the therapy suspension controlprocedure may include a therapy suspension request verificationprocedure to verify the therapy suspension request.

The device and subject monitoring procedure 2422 may be implemented inthe control and computing module 2416 to monitor the status of the AMD(e.g., therapy delivery configuration) and the health condition of theuser 2414 (or a subject). For example, when the device and subjectmonitoring procedure 2422 receives the request for therapy suspension,it may send a signal to the medicament dose control procedure 2420indicating that no does control signal should be send to the medicamentdelivery interface 2402 during the period request by the user 2414. Insome cases, if during the suspension period, certain pre-set conditionsare satisfied, the device and subject monitoring procedure 2422automatically resumes the therapy delivery by sending a signal to themedicament dose control procedure 2420. For example, if during thesuspension period the subject sensor 2406 detects an elevation of thelevel of one or more analytes in subject's blood and/or interstitialfluid beyond a set threshold, it may resume the medicament delivery tothe user 2414 by a sending a dose control signal to the medicamentdelivery interface 2402.

In order to prevent inadvertent activation of a suspension, the user mayinitiate a therapy suspension request starting with a wake action (e.g.,received by the wake interface 2408 and processed by the wake controlprocedure 2424), that activates the user interface module 2404. Using afirst interaction with a user interface (e.g., a touchscreen display2410 or alphanumeric pad 2412) the user may unlock a therapy suspensionuser interface where the information pertaining therapy suspension isprovided. Next, the user may confirm the requested therapy suspensionusing a second interaction with the user interface. In some examples,the system may allow access to the therapy suspension user interface andaccept the suspension request, when the first and second interactionwith the user interface are verified by the therapy suspension controlprocedure 2426.

In some examples, the therapy suspension control procedure 2426 mayreceive the request for suspension and suspension information fromanother device connected to the ambulatory medical device 600 (e.g.,through the communication module).

The suspension information provided by the user may include a set ofparameters needed for a suspension. For example, the suspensioninformation may include the dates and/or times for starting and endingthe therapy suspension, threshold values needed to define a thresholdcondition that may trigger an early resumption of the therapy delivery,and the like. In some other examples, suspension information mayindicate that the suspension of therapy should happen at a particulartime or after a particular event (e.g., after the next dose ofmedicament is delivered or after the condition of the subject reaches aparticular state, such as the middle of a desired blood glucose range).In some examples, the threshold values may be associated with inputprovided by the subject sensor 2406 or other types of sensors that maybe used to monitor one or more parameters associated with the healthcondition of the user 2414.

The parameters for a suspension may include the start and stopconditions for a suspension. The start condition for a suspension may bea condition that, when met, activates a suspension. In some suchexamples, the start condition is met when a timer runs out. Similarly,the stop condition is a condition that, when met, ends the suspension.In one example, the stop condition is met when a timer runs out. Inanother example, the stop condition is met when a threshold is met. Athreshold may be related to a measurement taken by ambulatory medicaldevice (e.g., by a subject sensor 2406), such as a glucose concentrationof the blood of a user. The threshold may be met if the glucoseconcentration goes above, goes below, or matches a set concentration.Multiple conditions may be set by the suspension request interfacecomponent. For example, a time condition and a threshold condition maybe set simultaneously. A user may specify that a suspension will endafter a set time. However, the suspension may end sooner than the settime if the glucose concentration of the user meets a threshold.

In some cases, the request to suspend therapy may include an indefinitesuspension period. In other words, the request may not include a timeperiod specified by a user or an identity of a resumption condition. Insome other cases, the indication may include a request to temporarilysuspend delivery of therapy for a defined period of time or until afurther interaction or event occurs. Thus, the resumption condition caninclude an expiration of time or an active event (e.g., a command or adetermined condition of a subject). Further, the therapy to be suspendedmay include any type of therapy. For example, the therapy to besuspended may be the suspension of the delivery of medicament, which mayinclude insulin, counter-regulatory agent (e.g., Glucagon), or bothinsulin and a counter-regulatory agent. In some cases, the ambulatorymedicament device may be capable of and/or configured to administermultiple medicaments (e.g., both insulin and a counter-regulatoryagent). In some such cases, the request to suspend therapy may include arequest to suspend one (e.g., insulin or the counter-regulatory agent)or both of the medicaments.

The interactions with the user interface may include the selection of anicon, a series of taps or inputs, one or more gestures (e.g., a swipe orother simple or complex movement across the touchscreen), performing apattern or sequence on the touchscreen (e.g., drawing an image), amulti-touch or multi-input interaction, a combination of the foregoing,or any other type of interaction with a touchscreen, or portion thereof.The series of inputs may be any combination of touch movements, touchpoints, numerical characters, alphabetical characters, and othersymbols. In some examples, the first and/or second user interactions mayinclude a predetermined sequence of numerical or alphabetical inputs. Insome examples, a series of multiple inputs, the range of parameters foran input may be dependent on other inputs in the series. For example,required start position of a touch movement may be dependent on theposition of the previous touch movement. The time that the series ofinputs are entered may also be a part of the range of parameters. Forexample, a series of inputs may need to be entered in no less than 3seconds or more than 3 seconds, and no more than 15 seconds or less than15 seconds. In some cases, a visual guide may assist the user ingenerating the user interaction. For example, one or more arrows orimages may be presented to the user to guide the user in providing thecommand to suspend the delivery of therapy.

Further, one or more of the interactions may include interacting with asensor as an optical sensor (e.g., visible light or IR sensor),biometric sensor (e.g., a fingerprint or retinal scanner), a proximitysensor, a gyroscope, or a combination of accelerometer and gyroscope,and the like. Also, in an exemplary embodiment, the second userinteraction may be made through a wireless signal such as RFID orBluetooth. In some embodiments, the second user interaction may includereceiving a selection of an indicator box that correspond to eitherinsulin or glucagon and receiving a predetermined sequence of numericalinputs in order to deliver the therapy change selection.

The type of user interaction that unlocks the touchscreen, providesaccess to a therapy suspension user interface, or confirms a suspensionrequest may be the same or may differ.

In an exemplary embodiment, the system may have a time-out such that ifno interaction occurs for a set period of time at each step during thetherapy suspension request process, the user interface will turn off andthe therapy suspension request process has to start again. In oneimplementation of the time-out, if no interaction occurs for more than30 seconds after the system is waked/unlocked before the second userinteraction is received by the user interface, the user interface willbe deactivated.

FIG. 25 is a flow diagram illustrating an example method for receivingand implementing a suspension request, which may be implemented by anAMD. In this example the user may use a touchscreen interface to requestand confirm a therapy suspension. Once the user activates thetouchscreen using a wake action 2502, the AMD may wait for a firstgesture on the touchscreen. After the user provides the first gestureand the gesture is verified by the therapy suspension control procedure2426, a therapy user interface may be activated 2506 where the user canrequest a therapy suspension and provide 2508 the suspension information(e.g., a start day/time and stop day/time and/or a resumptioncondition). Next, the AMD may wait for second gesture on the userinterface 2510. If the second gesture is received and verified by thetherapy suspension control procedure 2426, the therapy delivery will besuspended 2512. If the second gesture is not received or not verified bythe therapy suspension control procedure 2426, the therapy suspensioncontrol procedure 2426, may determine if a set time has passed sincereceiving the therapy suspension request 2514. If it is determined thata set time has passed since receiving the therapy suspension request,the request will be canceled, and the touch screen will be locked 2516.If it is determined that time from receiving the therapy suspension isless than a set time the AMD may wait for the second gesture to bereceived.

In some examples, once a wake action is received 2502, the AMD mayautomatically activate a therapy suspension user interface 2506, withoutthe need for a first gesture 2504. In these examples, once the requestfor therapy suspension is received 2508, a gesture (e.g., a firstgesture) may be required to verify the request. In some such examples,once the therapy delivery is suspended, a second gesture may stop asuspension before any of the conditions of the stop parameter are met.This allows the user the versatility of being able to modify asuspension that has been activated.

FIG. 26 is an illustration of a plurality of screens 2600 that theambulatory medical device may display when a user activates a therapysuspension user interface. Screen 2602 shows a user interface that anambulatory medical device may display to a user 2414. The display may bea touchscreen display 2410 that can accept input that includes the firstand second gestures. The therapy suspension system (ambulatory medicaldevice 600) is not limited to the displays shown in FIG. 26. Variousdisplays may communicate, to the user 2414, the same information shownin FIG. 26. The screen 2602 allows the user 2414 to select variousfunctions. The pause button 2612, shown on screen 2602 is a functionthat suspends the delivery of a medicament to the user 2414. When thepause button 2612 is selected, the user 2414 is treated to the pausescreen 2604. The pause screen 2604 allows the user 2414 to select aduration of the medicament suspension. The ambulatory medical device 600may display various interfaces to allow the user 2414 to select aduration of the medicament suspension. The pause screen 2604 shows asimple interface, giving the user 2414 one of two duration options.

When the user 2414 has made a selection of the duration of themedicament suspension on the pause screen 2604, the pause screen 2606shows the user 2414 the duration 2614 that the user 2414 selected (e.g.,in the figure the user 2414 selected 1 hour. Thus, the medicamentdelivery is suspended for 1 hour after the suspension begins). The pausescreen 2606 has a prompt 2608 for the user to make a gesture to confirmthe requested suspension before the medicament suspension begins. Asshown by the prompt 2608, the user 2414 is being prompted to swipe rightacross the bottom of the screen. Once the user 2414 performs the gestureto begin the medicament suspension, the suspension screen 2610 isdisplayed on the touchscreen. The suspension screen 2610 informs theuser 2414 that the medicament is paused. The user 2414 has the option ofperforming another gesture to unlock the ambulatory medical device. Theprompt 2616 for the user 2414 to unlock the device forces the user toperform another swipe to execute more functions on the ambulatorymedical device 600.

Suspending the medicament delivery may occur by not generating a dosecontrol signal to deliver a dose of medicament. Alternatively, or inaddition, suspending the medicament delivery may occur by sending asignal to the medicament pump to cease providing therapy or medicamentto the subject.

In some cases, the ambulatory medicament device may not immediatelysuspend therapy upon receiving a command to suspend therapy. Forexample, if the ambulatory medicament device is in the process ofdelivering medicament or determines that a condition of the subjectindicates that medicament may soon be required to maintain the subject'scondition (e.g., blood glucose) within a particular state (e.g., withina desired blood glucose range), the suspension of therapy may be delayeduntil at least such time that medicament is not being delivered, ispredicted to not be required during the suspension period, or the nexttherapy has been delivered. In some such cases, the ambulatorymedicament device may inform that user that the suspension of therapy isbeing delayed. Further, the ambulatory medicament device may indicatethe reason for the delay. In some cases, the user may be able tooverride the delay and request immediate suspension of therapy. Forexample, if the user is replacing the medicament cartridge, the user mayoverride an indication that the suspension of therapy should be delayed.In some cases, the requested start time may be overridden by adetermined condition of the subject.

The suspension of therapy or the suspension of the delivery ofmedicament may continue until a resumption condition occurs. In certaincases, when a resumption condition is met, the suspension period mayautomatically end without action by the user or subject.

The resumption condition may include the expiration of a time period, acommand from a user (e.g., the subject), detection that the ambulatorymedicament devise satisfies a condition (e.g., that medicament has beenrefilled), that the condition of the subject meets certain criteria(e.g., the subject's blood glucose level drops below a threshold rangeor rises above a threshold range), or any other condition that maysatisfy the reason for suspension of therapy or that overrides therequest for suspension of therapy. For example, the drug delivery devicemay be configured to automatically resume drug delivery when a glucosethreshold is reached or exceeded. This threshold could be set to 300mg/dl for example. The resumption condition may include detection of animpending risk of hypoglycemia or hyperglycemia, or a hypoglycemia orhyperglycemia event. Further, the resumption condition may include ameal announcement, or an “exercise concluded announcement,” a motionsensing event, a pause of other administered medicament, a conclusion ofan undefined suspension length (e.g., during cartridge change), aspeed-based resumption event, a location-based resumption, a remoteresumption in case of an emergency (e.g., commanded from caregiver adminsoftware or clinician), or any other type of resumption event. In somecases, the resumption condition can include a combination of criteria.

In some cases, automatically resuming therapy may include discontinuingthe suspension of therapy before the expiration of the suspensionperiod. For example, if a condition that caused therapy to be suspendedis resolved prior to the expiration of the suspension period, therapymay be resumed.

In some cases, when a resumption condition (provided by the user) ismet, the ambulatory medicament device may confirm that one or moreadditional conditions of the ambulatory medicament device are satisfiedbefore therapy is resumed. For example, if the ambulatory medicamentdevice determines that medicament has not been refilled or if there is aproblem with the refill (e.g., cartridge is incorrectly installed), theambulatory medicament device may continue to maintain the suspension oftherapy despite the trigger to resume therapy.

In some examples, a therapy suspension may be ended if a thirdinteraction with a user interface (e.g., a gesture) is detected. Thethird user interface interaction may be detected by the user interfacemodule 2404 and sent to the therapy suspension control procedure 2426.If the therapy suspension control procedure 2426 verifies that thirdinteraction with the user interface is a predetermined third userinterface interaction, it may send a signal to the device and subjectmonitoring procedure 2422 to activate the medicament dose controlprocedure 2420. This allows the user the versatility of being able toend a suspension that has been activated, during the suspension periodset by the user before the confirmation (second interface with the userinterface). In some cases, a user may decide to end a therapy suspensionto modify one or more suspension conditions set prior to activation ofthe current therapy suspension. In some other examples, user may decideto end a therapy suspension due to change in user's health condition notincluded in one or more therapy resumption conditions provided beforeactivating the current therapy suspension.

FIG. 27 is a flow diagram illustrating an example method of resuming asuspended therapy that may be implemented by an AMD. Once a therapysuspension has been requested and confirmed by a user (e.g., using theprocedure illustrated in FIG. 10) 2702, the AMD suspends one or moretherapies selected for suspension 2704 at suspension initiation timereceived as part of the suspension information. For example, therapysuspension control procedure 2426 deactivates the medicament dosecontrol procedure 2420 using the device and subject monitoring procedure2422. During the suspension period, the therapy suspension controlprocedure 2426 continuously monitors the system clock and the subjectand device condition (e.g., using medicament dose control procedure2420).

If the therapy suspension control procedure 2426 determines that thetime passed since the suspension initiation is less than the requestedsuspension time period 2706 and none of condition for resumption hasbeen met 2708, the therapy suspension continues.

If the therapy suspension control procedure 2426 determines that thetime passed since the suspension initiation is equal to the requestedsuspension time period 2706, or one or more resumption conditions havebeen met 2708, it may check other AMD or subject conditions (notincluded in the therapy suspension information), in order to determinewhether the therapy delivery can be safely resumed 2710. If it isdetermined that the therapy delivery cannot be safely resumed, an alertmessage will be sent to the user interface to inform the about thereason for such determination 2714. If it is determined that the therapydelivery can be safely resumed, the one or more suspended therapies willbe resumed 2712.

FIG. 28 is an illustration 2800 of a plurality of screens that may bedisplayed, for example, on a touchscreen display when a user 2414resumes a suspended therapy. Screen 2802 informs the user that thedelivery of medicament is currently in a suspended mode. The screen 2812also shows the user 2414 the current glucose concentration of the bloodof the user 2414. The ambulatory medical device 600 may display variousvital measurements that are useful to the user 2414. In oneimplementation, the medicament suspension ends if the glucoseconcentration of the blood of the user meets or passes a threshold.

The interface screen 2804 allows the user 2414 to select and executevarious functions on the ambulatory medical device 600. The resumebutton 2814 is a function that ends a medicament suspension. When theresume button 2814 is selected, the ambulatory medical device 600displays a resume screen 2806. The resume screen 2806 has a prompt 2816that prompts the user 2414 to perform a gesture. In the examples shown,the user 2414 receives a prompt 2816 in the resume screen to swipe rightacross the bottom of the resume screen 2806. The requirement to performthe gesture to resume medicament delivery prevents the user 2414 frominadvertently resuming medicament delivery in the ambulatory medicaldevice 600.

Once the user 2414 performs the gesture to resume medicament delivery,the medicament suspension ends. The resumption screen 2808 shows theuser 2414 that the regular medicament delivery has resumed. Once theresumption screen 2808 has been displayed to the user 2414 for asufficient amount of time to inform the user 2414 that the suspension isending, the ambulatory medical device 600 may display a lock screen2810. The lock screen 2810 prevents the user 2414 from inadvertentlyexecuting more functions on the ambulatory medical device 600.

In one embodiment, the ambulatory medical device 600 may end thesuspension before the one or more conditions to end the suspension aremet, when it receives a second gesture. The purpose of the secondgesture is to ensure that the user 2414 does not inadvertently end thesuspension. Like the first gesture, the second gesture may be simple orcomplex.

With reference to FIG. 24, once the AMD device is instructed to resumetherapy and/or determines that therapy is to be resumed, the ambulatorymedicament device may determine whether a dose of medicament should besupplied to the user based on a control algorithm used by the ambulatorymedicament device to control the provisioning of medicament to thesubject. For example, the therapy suspension control procedure 2426 maydetermine a resumption condition has been satisfied or receive a userinput from the user interface module 2404 (a third interaction with auser interface) indicating that therapy suspension should be ended.Subsequently the therapy suspension control procedure 2426 may send asignal to the device and subject monitoring procedure 2422 to activatethe medicament dose control procedure 2420. If medicament is to besupplied, the medicament does medicament dose control procedure 2420 maygenerate and send a dose control signal to the medicament deliveryinterface 2402.

In some cases, the ambulatory medicament device may alert the userand/or the subject that therapy is being resumed. This alert may occurbefore generating a dose control signal and/or after a resumptioncondition is satisfied (e.g., a suspension time expires). In some cases,the user may request that the suspension of therapy end early. The usermay request the early resumption of therapy be interacting with theaforementioned user interface using one or more of the previouslydescribed interaction methods (e.g., gestures or taps).

Additional embodiments relating to suspending medicament delivery to asubject that can be combined with one or more embodiments of the presentdisclosure are described in U.S. Provisional Application No. 62/910,970,which was filed on Oct. 4, 2019 and is titled “METHOD FOR SU SPENDINGDELIVERY OF A DRUG INFUSION DEVICE WITH AUTOMATIC RESUMPTION OFDELIVERY,” the disclosure of which is hereby incorporated by referencein its entirety herein for all purposes.

AMD with Security Functionality

An ambulatory medicament device (AMD), such as, but not limited to, aninsulin pump, that provides life-saving treatment to subjects orsubjects based on the condition of the subject, may include a userinterface (e.g., a touchscreen display) that lets a user to modify thesettings of the ambulatory medicament device. The setting may include,but not limited to, a condition that triggers the delivery of medicamentto a subject, the quantity of medicament delivered when a condition ismet, type of the medicament and the like. The setting may also includefeatures of the AMD that may not be directly related to the medicamentdelivery (e.g., the screen brightness, an alarm sound, and the like). Insome examples, it is desirable to manage access to various settings ofAMD in order to avoid inadvertent changes while enabling changes thatmay be necessary for uninterrupted and proper operation of the AMD. Forexample, it may be desirable to limit the access to some settings tocertain authorized users (e.g., a healthcare provider) while enableaccess to some other settings other authorized users (e.g., the subject,a guardian or parent of the subject).

In many cases, a healthcare provider can modify the settings of theambulatory medicament device. However, it is often desirable that anon-healthcare provider modify at least some settings of the ambulatorymedicament device. For example, when the ambulatory medicament deviceruns out of or has below a threshold amount of medicament, it is oftendesirable that a user be able to refill or change a medicament cartridgewithout visiting a healthcare provider. In some cases, changing themedicament cartridge may include interacting with a user interfaceand/or one or more settings of the ambulatory medicament device. Anotherexample of when it is desirable for a non-healthcare user (e.g., asubject, parent, or guardian) to modify settings of the ambulatorymedicament device is when the initial settings of the ambulatorymedicament device are not providing the desired effect (e.g., sufficientmedicament, too much medicament, providing the medicament too slowly ortoo fast, etc.). In some cases, normal maintenance of the ambulatorymedicament device and/or subject may require interaction with theambulatory medicament device settings and/or controls. For example,negative consequences may begin to occur when an ambulatory medicamentdevice remains connected to a subject at the same site for more than athreshold period of time (e.g., for more than 2-3 days, more than 5days, more than a week, etc.). Thus, the ambulatory medicament devicemay need to be periodically moved from one site on the subject toanother site on the subject (e.g., from left-side to right-side, fromarm to leg, from stomach to back, etc.). The change in site location mayrequire interaction with settings of the ambulatory medicament device(e.g., pausing operation until the site change is completed).

Although, as explained above, there are a number of reasons it isdesirable to enable a user other than a healthcare provider (e.g., thesubject receiving therapy, a parent, or a guardian) to have access to atleast some user settings of an ambulatory medicament device, it is alsodesirable to regulate access to at least some of the ambulatorymedicament device settings. For example, it is generally undesirablethat a child (subject or otherwise), or a user below a particular age,have access to ambulatory medicament device settings that could causeharm to the subject if modified. Further, it may be undesirable forcertain subjects who have diminished mental capacity regardless of ageto have access to at least some ambulatory medicament settings.

The user may be a subject receiving medicament or therapy, or may beanother user, such as a clinician or healthcare provider, or a parent orguardian of the subject. In some examples, the passcode required forchanging one or more setting via an intermediary device may be differentthat the passcode required for changing the same settings directly usingthe AMD's user interface.

One solution to regulating access to settings of the ambulatorymedicament device is to implement a lock feature to require that a userprovide a passcode, a passcode, or other information before the user ispermitted to modify a setting of the AMD, such as a control parameter.To simplify discussion, the disclosure will describe using a passcode.However, it should be understood that the passcode can be substitutedfor a passcode or any other type of secret or semi-secret information.In some examples, when the AMD is in the locked state, it may continuedelivering therapy to the subject at the same rate as unlocked state.

The lock feature may be activated by default or may be activated by auser. In some examples, the lock feature can be enabled through asetting in a control menu of the AMD device provided on a user interface(i.e., touchscreen display). The setting may include an on/off toggle(e.g., a software interface element or a hardware interface element) sowhen the toggle is on, a passcode (e.g., 4 to 8 numeric digits) may berequired. In some cases, if the lock feature is on, the passcode (e.g.,a 4 to 8 numeric digit code) may be required to turn the lock featureoff. When the lock feature is activated, the user may program theambulatory medicament device with a user passcode selected by the user.Alternatively, or in addition, the user passcode may be set in responseto a passcode change request. In some cases, a user passcode may expire.In such cases, a user may be required to generate a new passcode afterthe previous passcode expires or before the previous passcode ispermitted to expire. In other cases, the ambulatory medicament devicemay periodically generate a new passcode (e.g., an override passcode),or may generate the passcode at a time when a user supplies thepasscode.

In some cases, the user interface element used for accessing a userinterface that enable changing one or more settings of the AMD maydiffer from the user interface for modifying the control parametersassociated with that setting. For example, a keypad may be used to entera passcode for unlocking a user interface for changing a controlparameter and a touchscreen may be used to modify the control parameter.

When the lock feature is enabled, the user interface screen may look andfunction the same as if the lock feature were not enabled. If the lockfeature is enabled, when a visual guide for unlocking the device (suchas, for example, a linear unlock slider, an arcuate unlock slider, oranother unlock user interface element) is activated, a passcode entryinterface (e.g., a keypad user interface element) may be displayed. Ifeither the user passcode or the global override passcode is entered, theuser interface may proceed as normal. Otherwise, the user interface mayrevert back to the original lock screen.

In some examples, the user action that permits a user to change one ormore settings of the AMD may be different from the wake action thatactivates a user interface. For example, a wake action may be used toactivate a touchscreen display that may display a plurality of userselectable elements some of which may be accessible without a passcode.In such examples, a subset of the user selectable elements, for examplethose allowing the user to change therapy control parameters, mayrequire a passcode. In some cases, access to each user parameter controlelement may require a different passcode. In some other examples,providing a passcode may to an AMD in locked state, may directly enableaccess to a subset of control parameter elements.

To help recall the passcode, the passcode may be set by the userenabling the user to select a passcode the user is more likely toremember. However, regardless of who sets the passcode, there is a riskthat the user will not remember the passcode. Due to the nature of thedevice (e.g., a device that may provide life-saving treatment), it isdesirable that certain users not be restricted from accessing particularsettings of the ambulatory medicament device, and be able to quickly(e.g., within seconds, minutes, prior to a next therapy event, or beforeharm may occur to the subject) obtain access to the particular settingswhen required. Thus, while some non-medical devices may implementlockout periods or other restrictions to prevent a malicious user fromtrying to brute-force determine a passcode for a device, such featuresare generally undesirable for an ambulatory medicament device.Accordingly, embodiments disclosed herein include an ambulatorymedicament device that includes an override passcode that enables accessto the ambulatory medicament device (or control settings thereof)regardless of whether the user passcode is provided.

In some examples the passcode or the override passcode can be a seriesof taps, series of inputs, a complex or a simple gesture (e.g., a swipeor other movement across the touchscreen), The series of inputs may beany combination of touch movements, touch points, numerical characters,alphabetical characters, and other symbols. In some examples, the timethat the series of inputs are entered may also be a part of the range ofparameters. For example, a series of inputs may need to be entered in noless than 3 seconds or more than 3 seconds, and no more than 15 secondsor less than 15 seconds. One example of the complex gesture is a swipe.

In some other examples the passcode or the override passcode can be acomplex or a simple gesture (e.g., a swipe or other movement across thetouchscreen), performing a pattern or sequence on the touchscreen (e.g.,drawing an image), a multi-touch interaction, a combination of theforegoing, or any other type of interaction with a touchscreen, orportion thereof. Another example of a complex gesture is entering apredetermined sequence of touches. In some cases, the passcode mayinclude a quiz or set of questions,

In some examples, the ambulatory medicament device may be configured toreceive therapy settings or modifications to therapy settings from anintermediary device via a communication connection. In some cases, thisfeature may be supported in addition to providing the user with optionof modifying one or more settings with a user interface of the AMD. Thecommunication connection between the intermediary device and the AMD maybe a direct connection via, for example, Bluetooth®, or a connection viaa network, such as over a local area network or a wide area network. Insome such cases, the ambulatory medicament device may include a wirelesstransceiver, such as an NB-LTE transceiver, a Wi-Fi transceiver, or aBluetooth transceiver. The intermediary device, that provides the userwith a user interface to modify settings of the AMD, include any type ofdevice (e.g., a computing device) that can communicate with anambulatory medicament device. For example, the intermediary device maybe a laptop or desktop computer, a smartwatch, a smartphone, or ahardware control device that may be configured to interact with theambulatory medicament device. Embodiments disclosed herein areapplicable regardless of whether the user interface for modifyingtherapy settings or the configuration of the ambulatory medicamentdevice is generated or presented by the ambulatory medicament device tothe user or via another device. In some such cases, a user may provide auser-generated passcode or an override passcode via an interface of thecomputing device. The computing device may then provide theuser-generated passcode or the override passcode to the ambulatorymedicament device via the network connection between the devices.

In some examples, even if the AMD is in locked state, certainintermediary devices may have access to user interfaces that may be usedto change one or more settings (e.g., therapy settings) of the AMD. Forexample, the smart phone of a guardian or a parent of the subject may beused to change one or more settings of the AMD while the AMD is in thelocked state.

In some examples, the AMD may be configured to receive a passcode fromor via a computing systems (e.g., a cloud computing system). In theseexamples, the AMD may receive passcode through a direct end-to-endconnection (e.g., a wireless connection over a wide area network)stablished with the computing system. In some such examples, anothercomputing device (e.g., a smartphone, a laptop, a personal computer, andthe like) connected to the computing system, may send a passcode to theAMD and be able to change one or more settings of the AMD if thepasscode is validated by the AMD.

In cases where the user cannot recall the user passcode, the user canobtain access to the user interface that permits modification of thecontrol parameter by supplying an override passcode. In some examples,the override passcode may be a universal fixed passcode (e.g., an8-digit override passcode) that can be used instead of the user setpasscode. The override passcode can be stored in the ambulatorymedicament device at the time of manufacture and may be shared amongmultiple ambulatory medicament devices (e.g., a global overridepasscode), or may be unique to a particular ambulatory medicamentdevice. The override passcode may be managed by the manufacturer or by athird-party service. To obtain the override passcode, the user maycontact the manufacturer or passcode managing service. Generally,enabling the passcode may exist to prevent a user with a diminishedmental capacity (e.g., a child) from modifying settings of theambulatory medicament device. Thus, security may be less of a concernand any user can contact the manufacturer or passcode managing serviceto obtain the override passcode. In some such cases, a single globaloverride may be used for all devices produced by the manufacturer.However, in some cases, a level of security may be desired. In some suchcases, it may be necessary for the user to authenticate him or herself.Further, the user may be required to provide a serial number of theambulatory medicament device. In some cases, each model or each unit ofthe ambulatory medicament device may have a different override passcode.The user may provide authorization information and a serial number ofthe ambulatory medicament device to the manufacturer or passcodemanaging service to obtain the override passcode.

In some examples, may periodically generate a new override passcode ormay generate an override passcode at a time when a user supplies thepasscode. In these examples, the ambulatory medicament device may usethe same parametric values to generate the override passcode as anotherdevice may use thereby ensuring a match between the override passcodes.Advantageously, in some cases, by using an algorithm to generate theoverride passcode, the override passcode can be obtained regardless ofwhether a user is able to contact a manufacturer or other passcodemanaging service. In some cases, the user may generate the overridepasscode without access to a network or phone using, for example, acomputing device that can access a common parameter value as theambulatory medicament device.

In some cases, the override passcode may change over time or be arotating passcode. For example, in some cases, the override passcode maychange every thirty seconds, every minute, every hour, etc. In some suchcases, the override passcode may be determined from an algorithmexecuted by an application. The ambulatory medicament device may store acopy of the algorithm in a memory of the ambulatory medicament deviceand may execute the algorithm to determine the override passcode that iscurrently valid. A copy of the algorithm may be executed by anothercomputing device accessible by the user. The output of the algorithm maybe based on a value that is commonly accessible by the ambulatorymedicament device and the copy of the algorithm accessible by thecomputing device. For example, the output of the algorithm may begenerated based on a time, a user identifier, a provided value, or anyother factor that may be used to repeatedly generate the same output. Insome cases, the override passcode may be calculated based on acombination of factors. For example, the override passcode may becalculated based on a portion of a serial number or model number for theambulatory medicament device and the time. The determination of theoverride passcode may be calculated by the ambulatory medicament device,a computer server, and/or an application on a user device.

In some cases, the override code can be automatically received by theambulatory medicament device. Thus, a user may not need to see or enterthe override code. In some cases, the override code may be transmittedto another device of the user (e.g., a smartphone or laptop). Forexample, the override code can be texted to a user's smartphone. In somecases, the override code may be received in a coded manner that may notbe understandable by a child or user with diminished mental capacity.

In some cases, the override passcode may be linked to a location. Forexample, the override passcode may be enterable at a healthcareprovider's office or at the subject's place of residence. Thedetermination of the location of the ambulatory medicament device may bebased on a geolocation system (e.g., a Global positioning System (GPS))available to the ambulatory medicament device.

In some examples, at least for a subset of therapy settings, thepasscode may provide a second level of security in addition to otherinteractions with the user interface (e.g., a first and a second gestureon a touchscreen display) that may be used to change the therapysettings and/or accept the change made to a therapy setting. In someother examples, at least for a subset of settings, the passcode may beused instead of other interactions with the user interface (describedabove).

As mentioned above, interacting with the user interface may cause theambulatory medicament device, or other device that can modify a controlof the ambulatory medicament device, to present a passcode input screento the user. The user may enter the passcode to unlock additional userinterface features including, for example, a user interface that enablesthe user to modify at least one control parameter of the ambulatorymedicament device. The control parameter can be modified based on aninteraction with a parameter control element of the user interface.Further, modification of the control parameter may cause modification ofthe generation of a dose control signal that is generated by a controlalgorithm based at least in part on the control parameter.

In some embodiments, the ambulatory medicament device may have anadvanced therapy screen, or other user interface, that permits ahealthcare provider, or other user, to obtain additional detailsrelating to therapy provided by the ambulatory medicament device.Although the advanced therapy screen may generally be intended for aknowledgeable user, such as a clinician, in some cases, any user mayobtain access to the advanced therapy screen. The advanced therapyscreen may permit the healthcare provider to modify control parametersthat may not be modifiable by other users. For example, the healthcareprovider may be able to control parameters that relate to thecalculation of a rate of insulin accumulation, the rate the insulindiminishes within the blood of the subject, the setting of a glucosesetpoint, an aggression level or factor of therapy relating to an amountof insulin provided when the subject's glucose level is outside thesetpoint range, or when the insulin reaches a point of maximumconcentration within the blood of the subject (e.g., T_(max)).

Access to the advanced therapy screen may be limited by requirement of apasscode, which may be referred to as a clinician passcode todistinguish it from the user-generated passcode and/or the overridepasscode. This clinician passcode may or may not be user-generated.However, the clinician passcode may be a separate passcode from theuser-generated passcode that permits access to the non-advanced therapyscreen interface. Further, the clinician passcode may be separate fromthe override passcode that permits a user to override the user-generatedpasscode to obtain access to the non-advanced therapy screen interface.In some cases, the clinician passcode may be used as an overridepasscode. In some example the clinician passcode can be valid for periodof time (e.g., set by a subject or another authorized user such as theguardian or apparent of the subject). For example, the clinicianpasscode may be valid for a day, a week, or a month. In some examples,the AMD may allow certain authorized users to terminate the clinicianaccess at any time.

In some cases, access to the advanced therapy screen may be limited to aparticular period of time. After the time period expires, the ambulatorymedicament device may automatically restrict access to the advancedtherapy screen. In some cases, the window of access may be extended. Forexample, if the healthcare provider is continuing to interact with theadvanced therapy screen, the screen may remain accessible.

In some cases, the advanced therapy screen may provide additionalfeatures. For example, while a user may be able to indicate that anamount of insulin provided for a meal or as a correction factor shouldbe higher or lower, the healthcare provider may be able to specificallyadjust the amount of insulin. Moreover, while a user's direction may ormay not be followed depending, for example, if the request exceeds athreshold or may cause blood glucose to not satisfy a setpoint range, anindication provided via the advanced therapy screen may be followedregardless or may have a wider range or different threshold that maycontrol whether the instruction is followed. Further, the advancedtherapy screen may be used to temporarily pause therapy and/or mayprevent subject access.

In some cases, the manufacturer of the ambulatory medicament device mayprovide a remote unlock signal that can be used to unlock access to theambulatory medicament device and/or to an advanced therapy screen of theambulatory medicament device.

As described above, the passcode may be desired to prevent particularusers from inadvertently changing certain control parameters of theambulatory medicament device. However, features of the ambulatorymedicament device that do not affect therapy may remain accessible to auser when the ambulatory medicament device is in a locked state. Forexample, a user may be able to access therapy history, screen brightnesssettings or colors, or any other feature that is unlikely to harm asubject if modified in a particular manner. Further, as the passcodefeature is generally to prevent control parameter changes, theambulatory medicament device may provide therapy and continue to providetherapy at the same rate and under the same condition, whether or notthe ambulatory medicament device is locked or unlocked.

When the ambulatory medicament device receives the user passcode or theoverride passcode, the ambulatory medicament device validates thepasscode. The passcode may be validated by comparing the receivedpasscode to a passcode stored in a memory of the ambulatory medicamentdevice or generated by the ambulatory medicament device. If the passcodereceived from the user is successfully validated, the user may begranted access to a user interface to modify one or more controlparameters. In some cases, the user may be requested to re-enter apasscode to confirm a change to a control parameter. In some otherexamples, the user may be requested to provide a gesture on atouchscreen to confirm a change to a control parameter.

If the passcode is not validated, the ambulatory medicament device, orother control device that can provide access to control parameters ofthe ambulatory medicament device, may prevent access to the userinterface to modify the one or more control parameters. In some cases,the user interface that presents the user with the ability to enter thepasscode may permit the user a particular number of tries or aparticular number of tries within a particular time period to enter theuser passcode. If the correct user passcode is not entered within theprovided number of tries or within the particular time period, the userinterface may enter a lock state (e.g., the screen will be turned off)and prevent further attempts to enter a passcode for at least a periodof time. In some cases, the user passcode option may be indefinitelylocked or blocked. In some such cases, the control parameters of theambulatory medical device may be accessible when the override passcodeis provided. Alternatively, or in addition, a user passcode of adifferent user may be used to provide access to the control parametersof the ambulatory medical device. In some examples, if the correctoverride passcode is not entered within the provided number of tries orwithin the particular time period, the user interface may block anyattempt to change the override passcode for at least a period of time.

In some cases, once the passcode is successfully entered or validated, auser may deactivate the passcode feature of the ambulatory medicamentdevice. Deactivating the passcode feature may require use of a separatepasscode or the override passcode in addition to the user passcode.

In some cases, the passcode may be optional or omitted based on thecomputing device connected to the ambulatory medicament device. Forexample, if the end-to-end connection is established between asmartphone registered to a particular user (e.g., a parent of thesubject), the ambulatory medicament device may unlock automaticallywithout requiring a passcode. In other cases, the smartphone, or othercomputing device, may automatically provide the user-generated passcodeor the override passcode to the ambulatory medicament device uponestablishing a connection. In some cases, the ambulatory medicamentdevice may automatically be unlocked when connected to a charger or whenin a particular geographic area. For example, a geo-fence may beconfigured in one or more locations, such as the subject's house or theclinician's office. When the ambulatory medicament device determines itis within the geo-fence, the ambulatory medicament device mayautomatically be unlocked. Similarly, when the ambulatory medicamentdevice determines that it is not within the geo-fenced region, it mayautomatically be locked. The determination of the location of theambulatory medicament device may be made based on a geo-location system,such as the Global Positioning System (GPS).

In some cases, after a certain number of unsuccessful passcodes areentered (e.g., after 5 tries), the user interface screen may be turnedoff or may accept only the global override passcode.

Example AMD with Security Codes

FIG. 29 is a block diagram illustrating the interconnection amongmodules and procedures in AMD involved in changing the settings of theAMD. In some cases, one or more settings of the AMD may be changed usinga setting change input 2916 to one or more parameter control elementparameter control elements 2930/2934/2938 presented on one or moresetting user interface screens 2928/2932/2936 provided by the userinterface module 2902. In some examples, when the lock feature isactivated, access to one or more setting control screens 2928/2932/2936and/or one or more parameter control element 2930/2934/2938, may beprotected by a passcode. In order to change a parameter control element2930/2934/2938, the user may provide a passcode input 2918 (e.g., a usergenerated passcode or an override passcode), via the user interfacemodule 2902 (e.g., using a touchscreen display 2906 or alphanumeric pad2908). Alternatively, or in addition, the user 2910 may provide apasscode 2940 using an intermediary device (e.g., a laptop, a smartphone, and the like) that is connected to the AMD (e.g., via a wirelesslink). In some examples, the access to one or more setting userinterface screens 2928/2932/2936 and/or parameter control elementparameter control elements 2930/2934/2938, may be managed by settingchange procedures 2912 stored in a memory in the control and computingmodule of the AMD. A hard processor may execute the machine-readableinstructions associated with the setting change procedures 2912.

In some examples, the option to provide a passcode may become available,when the user 2910 performs a wake action on a wake interface 2904. Inthese examples if the wake control procedure 2922 of the CCM determinesthat a valid wake action is performed, it may present selectableelements associated with the setting user interface screens2928/2932/2936, for example, on a touchscreen display. In some otherexamples, the first screen presented on the touchscreen display, mayprovide other selectable elements including an element to change thesettings of the AMD. In such examples, selecting element associated withsettings change may activate a second screen that presents selectableelements associated with the setting user interface screens2928/2932/2936. When the lock feature is activated, access to any of thesetting user interface screens 2928/2932/2936 and/or parameter controlelement 2930/2934/2938 may require a passcode. In some examples, eachone of the user interface screens 2928/2932/2936 and/or parametercontrol element 2930/2934/2938 may require a different passcode. In someother examples, one or more user interface screens 2928/2932/2936 and/orparameter control element 2930/2934/2938 may not require a passcode. Forexample, access to the first user interface screen 2928 may require afirst passcode, the access to the second user interface screen 2932 mayrequire a second passcode and the access to the third user interfacescreen 2936 may not need a passcode. In yet another examples, all theuser interface screens 2928/2932/2936 may be presented without the needfor providing a passcode, but access to the one or more control elementsin a control screen may require a passcode. For example, the user mayselect the second user interface screen 2932 without entering a passcodebut in order to select one or more parameter control element 2934 onthat screen, the user may need to enter one or more passcodes.

In some examples, once a passcode or override passcode received from theintermediary device 2914 or the user interface module 2902, the passcodemay be transmitted to the control and computing unit of the AMD wherethe setting change procedures 2912 (therapy change control procedure2920 and wake control procedure 2922) determine the validity of thepasscode by comparing it to the one or more stored user generatedpasswords 2926 or received or stored override passwords 2924 stored in amemory of the CCM.

FIG. 30 is a flow diagram illustrating an example method that may beused by an AMD to allow a user to change a setting of the AMD using auser generated passcode or an override passcode. Once the AMD (e.g., thewake action procedure in the CCM) receives a valid wake action 3002, auser interface may be activated. In some example, the wake action maydirectly activate a setting change interface 3004 (e.g., a settingchange screen presented on a touchscreen display). In some examples, aspecific wake action may activate the setting change interface. On thesetting change interface 3006, the AMD (e.g., the setting changeprocedure in the CCM) may request a passcode (e.g., by presenting awindow to enter a passcode). Once a passcode is received, the AMD (e.g.,the setting change procedure in the CCM) may determine whether thepasscode matches a user generated passcode 3008. If it is determined thepasscode matches with a user generated passcode, the AMD may provideaccess 3010 to one or more control parameter elements associated withthe received passcode. If the received passcode dose not match with anyof the stored user generated passcode, the AMD may determine whether thepasscode matches with an override passcode 3012. If it is determined thepasscode matches an override passcode stored in a memory of AMD or amemory of an authorized computing device, the AMD may provide access3014 to one or more control parameter elements associated with thereceived override passcode. If it is determined the passcode does notmatches an override passcode, the AMD denies access 3016 to one or morepasscode protected control elements.

FIG. 31 is a flow diagram illustrating another example method that maybe used by an AMD to allow a user to change a setting of the AMD using auser generated passcode or an override passcode. Once the AMD (e.g., thewake action procedure in the CCM) receives a valid wake action 3102, theAMD may provide a user interface (e.g., a touchscreen display) on whichthe user can provide a first gesture to activate a setting changeinterface or screen. When a first gesture is received from a user orsubject 3104, the AMD may activate a setting change interface 3106 or ascreen. In some examples, the setting change interface or a screen mayinclude one or more parameter control elements associated with one ormore settings of the AMD. In some other examples, the setting changeinterface or a screen may include one or more selectable elements eachassociated with a setting change screen (e.g., a screen provided on atouchscreen display) that may include one or more control parameters.When a request for setting change is received 3108, the AMD maydetermine whether the requested setting change is passcode protected ornot 3110. In some examples, the request for setting change may includeselecting a parameter control element. In some other examples, therequest for setting change may include selecting a list of parametercontrol elements (e.g., included in a separate screen provided on atouchscreen display).

If the AMD determines that the requested setting change is not protectedby a passcode, it may permit access to one or more parameter controlelements associated with the requested setting change 3112. In someexamples, once the changes are received via parameter control elements3114, the user may need to provide a second gesture on the userinterface (e.g., touchscreen display) to confirm the changes made. Inresponse to receiving the second gesture 3116, the AMD may change one ormore settings 3118 according to the requested and confirmed changes.

If the AMD determines that the requested setting change is protected bya passcode, it may request a passcode 3120 via a passcode display (e.g.,provided on a touchscreen display). In some examples, the request forthe passcode may be presented on a display but the passcode may bereceived via a physical keypad. Once a passcode is received 3122 fromthe user or subject, the AMD may validate the passcode 3124 by comparingit with one or more user generated passcodes or an override passcode. Ifit is determined that the passcode matches with a user generatedpasscode or an override passcode, the AMD may activate 3126 one or moreparameter control elements associated with the requested setting change.Subsequently, the AMD may receive a setting change via the selectedcontrol parameter element 3128. In some examples, the user may need toprovide a second gesture on the user interface (e.g., touchscreendisplay) to confirm the changes made. In response to receiving thesecond gesture 3130, the AMD may change one or more settings accordingto the requested and confirmed changes 3132.

AMD with Alarm System

In some cases, a condition may occur that impacts the operation of theambulatory medicament device (AMD). This condition may be associatedwith the ability of the ambulatory medicament device to operate asintended by the manufacturer, a subject receiving therapy from the AMD,and/or user (e.g., healthcare provider, parent, or guardian of thesubject). In some cases, the AMD device may be operating as intended,but the condition of the subject may not satisfy a desired level ofhealth. In either case, it is generally desirable to generate an alarmto inform the subject and/or one or more users of the condition of theAMD and/or the subject. Moreover, it is desirable to track the alarmuntil the condition that caused the alarm is resolved. Further, it isdesirable to issue different types of alarms for different conditions toenable a subject or user to easily distinguish the severity of thecondition that triggered the alarm. The user may be a subject receivingmedicament or therapy, or may be another user, such as a clinician orhealthcare provider, or a parent or guardian.

This section of the disclosure relates to an AMD, such as an insulinpump or a combined insulin and counter-regulatory agent (e.g., Glucagon)pump, configured to generate a dose control signal configured to cause amedicament pump to infuse medicament into a subject. Moreover, thepresent disclosure relates to an ambulatory medicament device configuredto detect a condition of the ambulatory medicament device and/or thesubject, and to generate an alarm when it is determined that thedetected condition satisfies an alarm condition.

As mentioned above, an ambulatory medicament device may include an alarmsystem configured to monitor the ambulatory medicament device and/or thesubject, and to generate an alarm when it is determined that a conditionhas been detected that satisfies an alarm condition. In some examples,the alarm system may organize an alarm manager list, notify a user ofthese alarms, and/or allow the user to acknowledge alarms, mute, and/orsnooze the alarms. In some examples, the alarm manager list may be alist of pending alarm conditions with which the user can interact usinga touchscreen display of the AMD.

In some embodiments, the alarm system may include a plurality of sensorsthat monitor the AMD or the subject, a monitoring system interface thatreceives the data from sensors, and alarm generation module that processthe received data and generate alarms when an alarm condition is met. Insome examples, the monitoring system interface and the alarm generationmodule are implemented using one or more hardware processors and machinereadable. In some other examples, the monitoring system interface andthe alarm generation module are separate hardware modules. Inimplementations, the monitoring system may provide status informationreceived from the plurality of sensors to the alarm annunciation andcontrol system. In some examples, the status information may include oneor more status values. In some examples, the status information mayinclude device information pertaining to a condition of the AMD orsubject information pertaining to a condition of the subject. In somesuch examples, the alarm annunciation and control system may beconfigured to determine based at least in part on the status informationreceived from the monitoring system, whether an alarm condition issatisfied.

As noted above, the AMD may generate an alarm for various situations tonotify the user, and further may request a user's acknowledgement toconfirm that the user is aware of the current situation to be resolved.The alarm can be generated in various forms to the user in a way thatthe user can recognize the situation and condition of the alarm oralarms, thus allowing convenient communication between the user and theAMD.

With reference to FIG. 32, in some embodiments, an alarm system 3202 mayimplement alarm control procedures in a control and computing module(CCM) of the AMD. The alarm system 3202 can be implemented asinstructions stored in a memory of the CCM and executed by a hardwareprocessor to generate an alarm upon detection of a condition of theambulatory medicament device and/or the subject. In some cases, thehardware processor of the monitoring system may be a hardware processorof the ambulatory medicament device that controls medicament delivery.In some cases, the hardware processor of the monitoring system may be aseparate hardware processor.

In some examples, the alarm system 3202 may include a monitoring systeminterface 3210 and an alarm annunciation and control system 3212. Thealarm annunciation and control system 3212 may include sub-systems fordetermining the severity of an alarm condition, user notificationprocessing, and receiving alarm control commands from the user interfacemodule 3218. The user interface module 3218 may include any type of userinterface controller for providing a user interface. The user interfacemay be provided on a display of the AMD or may be transmitted to adisplay of an electronic device in communication with the AMD. In somecases, the user interface controller may be a touchscreen controllerthat is configured to output display signals configured to generate oneor more user interface screens on a touchscreen. Further, thetouchscreen controller may be configured to receive user input signalscorresponding to user interaction with the touchscreen. The monitoringsystem interface 3210 may monitor the condition or status of the AMDand/or the subject at least partially based on signals or status valuesreceived from a set of device sensors 3208 and a set of subject sensors3216. In some examples, the device sensors 3208 may be configured totrack the status of the components or the elements of the AMD, and thesubject sensors 3216 can be configured to obtain measurements of one ormore physiological characteristics of the subject. In some examples, thedevice sensor 3208 can include a motion sensor that detects motion oracceleration of the AMD or on the AMD (e.g., tapping or shakinggestures). The motion sensor can include an accelerometer, gyroscope,and/or other electrical or mechanical motion sensors that convert motionor acceleration into electrical signals.

In certain embodiments, the user 3226 may wake the AMD from a sleepstate or unlock the AMD by interacting with a wake interface 3220. Incertain embodiments, the user 3226 may wake the AMD from another stateor mode, such as for example a power saving mode or low power mode, theAMD by interacting with a wake interface 3220. When the AMD is in asleep state or other state/mode, the touchscreen controller may notreceive user input or user input signals corresponding to user input(e.g., via a touchscreen display 3222). When the AMD is in a sleep stateor other state/mode, the touchscreen controller may not receive userinteraction or user interaction signals corresponding to userinteraction (e.g., via device sensors 3208 including an accelerometer orother motion sensors).

Waking the AMD may include activating a touchscreen interface orpresenting a lock screen to a user. Further, waking the AMD may includewaking the touchscreen controller such that it can receive user input oruser input signals corresponding to user input. The wake interface 3220can include one or more of the additional user interfaces mentionedabove that are configured to generate and provide a wake input (or wakesignal) to the CCM when detecting a pre-set user interaction.Alternatively, or in addition, the wake interface 3220 can be any typeof wake interface element of the AMD that a user can interact with towake at least a feature (e.g., a touchscreen interface) of the AMD. Insome cases, the wake interface 3220 element can be a physical button(e.g., a push button, a slide button, etc.), a capacitive element, aresistive element, or an inductive element. In some cases, the wakeinterface element can be or can include a biometric element, such as afingerprint reader, an iris scanner, a face detection scanner, etc. Insome cases, the AMD may wake in response to detection of a particularmovement or motion. For example, a determination that the ambulatorymedicament device is being moved with a particular motion or within aline of sight or a visual range of a user may cause the AMD to awaken orcause the AMD to awake the touchscreen interface of the AMD. The AMD maydetermine that the AMD is being moved within a line of sight of the userbased on the type of motion and/or the detection of a user's eyes via,for example, an iris scanner or a camera. In some cases, the AMD maywake in response to detection of a tapping on the AMD, such as a singletap or a double tap. In some embodiments, a single tap or a double tapmay activate one or more elements of the user interface module 3218,such as for example the touchscreen display 3222. The touchscreendisplay can be a touch digitizer that converts analog interactions ofthe user (e.g., via electrical or mechanical properties of the user)into digital signals communicated to one or more controllers asdiscussed herein.

When in the wake and/or unlocked state, a user may interact with thetouchscreen display 3222, alphanumeric pad 3224, or other types of userinterfaces that may be included in the user interface module 3218. Theuser interface module 3218 may include any combination of one or more ofthe touchscreen display 3222, alphanumeric pad 3224, or other types ofuser interfaces.

In some examples, a device sensor 3208 may be a sensor that generates asignal or status value associated with the condition of modules,interfaces, accessories, disposables of the AMD. In some examples, adevice sensor 3208 may generate a signal that corresponds to a parameterassociated with a component in a module or interface. For example, onedevice sensor may record the voltage of a battery and another devicesensor may record the follow rate of a pump the medicament deliveryinterface 3214.

In some examples, a subject sensor 3216 may be any sensor that generatesa signal or status value associated with one or more physiologicalindicators (or parameters) of a subject (e.g., heart rate, bloodpressure, body temperature, level of blood sugar, serum levels ofvarious hormones or other analytes). In some such examples, the subjectsensor can be a continuous glucose monitoring sensor (CGS). The deviceand subject monitoring system interface 3210 may continuously receiveand analyze signals from device sensors 3208 and subject sensors 3216 todetermine the condition of the AMD, the subject, a sensor, and/or otheraccessories.

In some cases, a single sensor may be used to monitor both the conditionof the subject and the ambulatory medicament device or accessories andsensors connected to AMD. For example, a continuous glucose monitoring(CGM) sensor may be used to monitor the condition of the subject and mayalso be monitored to determine whether the condition of the CGMsatisfies an alarm condition (e.g., to alarm a user that the CGM shouldbe replaced).

Although described as sensors of the AMD, one or more of the sensors maybe accessories that may or may not be part of the AMD, but that maycommunicate with the AMD.

In some examples, the alarm system 3202 may implement procedures forallowing the user or subject to change the alarm settings and/oracknowledge an alarm annunciation via the user interface module 3218. Insome examples, the user may be able to see one or more alarmsannunciated on a user interface (e.g., as a list of alarms), even if theAMD is in a locked state. In these examples, the user may not be able toacknowledge or respond to alarms when the AMD is in the locked state.

In some such examples, the user or subject may access an alarm settingscreen or acknowledge an alarm annunciation by providing a wake actionor a wake action followed by a first gesture via, for example, thetouchscreen display 3222. In some cases, the first gesture may becreated by entering predetermined or particular characters on thealphanumeric pad 3224. In some such examples, the user or subject mayaccess an alarm setting screen or acknowledge an alarm annunciation byproviding a single, double, or more tap gestures on the AMD. In somesuch examples, the alarm system 3202 may distinguish inadvertent alarmcontrol inputs from intentional alarm control inputs. An inadvertentalarm control input may be an alarm acknowledgment input that was madewithout the intent of the user 3226 to acknowledge the alarm that theambulatory medical device is delivering to the user. For example, aninadvertent alarm acknowledgment may include one that was accidentallyexecuted by the user 3226 by putting pressure on the AMD in a jacketpocket of the user 3226.

In some examples, the alarm system 3202 may implement processes fordetermination and categorization of an alarm condition based on itsseverity level (e.g., a severity level between 0 and 5, with for example0 being least or nonurgent alarm conditions and 5 being urgent or mosturgent alar conditions), according to information received through themonitoring system interface 3210. In some examples, once an alarmcondition is detected, the alarm annunciation and control system 3212may place it in the appropriate queue, for example, based on severity orcategory. In one or more embodiments, a list of alarms may be generatedwherein alarms may be sorted numerically in descending order with thehighest priority fault or most urgent alarm condition displayed at thetop.

In some examples, the alarm system 3202 may implement procedures forcontrolling the annunciation of alarm conditions via the user interfacemodule 3218, at least partially, based on their severity level. In somesuch examples, a user interface (e.g., a touchscreen display) may beconfigured to allow the user 3226 to navigate directly to the issue orfault for which an alarm is being delivered and to address the faultcausing the alarm so that it may be corrected, thereby stopping thealarm. Additional embodiments relating to alarm condition for anambulatory medicament device that can be combined with one or moreembodiments of the present disclosure are described in U.S. ProvisionalApplication No. 63/167,563, which was filed on Mar. 29, 2021 and istitled “AMBULATORY MEDICAMENT PUMPS WITH SELECTIVE ALARM MUTING,” thedisclosure of which is hereby incorporated by reference in its entiretyherein for all purposes.

Alarm Conditions

In some examples, the device and subject monitoring system interface3210 may provide a status information received from the device sensor3208 and/or subject sensor 3216 to the alarm annunciation and controlsystem 3212. In some examples, the status information may include one ormore status values. In some examples, the status information may includedevice information pertaining to a condition of the ambulatorymedicament device or subject information pertaining to a condition ofthe subject. In some such examples, the alarm annunciation and controlsystem 3212 may be configured to determine based at least in part on thestatus information received from the monitoring system interface 3210,whether an alarm condition is satisfied.

Determining whether an alarm condition is satisfied may includecomparing one or more status values associated with the AMD and/or thesubject to one or more alarm thresholds, threshold amounts, or alarmconditions. In some cases, each alarm threshold, threshold amount, oralarm condition may be associated with an alarm profile. In some suchcases, determining whether the alarm condition is satisfied may includecomparing the status information to one or more alarm thresholds,threshold amounts, or alarm conditions included in one or more alarmprofiles. In some examples, the alarm profile may be stored in a memoryof the AMD. In some such examples, at least some of the alarm profilesmay be provided by an authorized user or the subject via a userinterface or directly transferred from another device to the storage(e.g., from USB drive, a laptop, smart phone, PC, and the like). In someexamples, at least some of the alarm profiles may be provided at thetime of manufacture.

Each of the alarm profiles may indicate the characteristics or status ofthe AMD and/or subject that triggers an alarm corresponding to the alarmprofile. For example, at least some alarm profiles may indicate thethreshold status values below or above which an alarm should betriggered. For example, one alarm profile may indicate that when a bloodglucose level of the subject exceeds a particular threshold, aparticular alarm is to be generated and/or annunciated. As anotherexample, an alarm profile may indicate that when an available amount ofmedicament is below a particular threshold, a particular alarm is to begenerated and/or annunciated. The type of alarm and/or the alarmfrequency or intensity associated with the medicament level may differfrom the alarm triggered based on the blood glucose level. Although theprevious examples described a single condition associated with a singlealarm profile, it should be understood that multiple conditions may beassociated with an alarm profile. For example, a blood glucose levelthat exceeds an upper threshold or is below a lower threshold may beassociated with different alarm profiles or the same alarm profile. Asanother example, a blood glucose level that is above an upper thresholdor a medicament pump that is unable to supply insulin may be associatedwith the same alarm profile. On the other hand, a medicament pump thatis unable to supply insulin due to an empty insulin cartridge may beassociated with a different alarm profile than when the medicament pumpis unable to supply insulin due to damage to the medicament pump.Advantageously, by having unique annunciation patterns for at leastcertain alarm conditions, a user can instantly know the stated of theAMD and/or subject based on the annunciation pattern for the alarm.

When an alarm condition is satisfied, the alarm annunciation and controlsystem can implement an annunciation pattern or alarm conditionannunciation pattern selected based at least in part on the statusinformation generated by and/or received from the monitoring system. Theannunciation pattern may be selected from a plurality of annunciationpatterns based at least in part on the alarm condition and/or the statusinformation. The annunciation pattern may include one or more differenttext patterns or text information, auditory alarms, visual alarms, orhaptic alarms.

Some non-limiting examples of conditions of the AMD or of the subjectthat may be associated with an alarm profile include conditions relatingto a battery capacity (e.g., below a threshold charge capacity or belowa capacity associated with a particular amount of operating time (e.g.,one day)), a battery condition (e.g., high temperature or low voltage),a medicament or drug delivery condition (e.g., medicament is empty orbelow a threshold, motor is stalled, catheter is occluded, etc.),subject sensor condition (e.g., blood glucose sensor is expiring, orsignal was not received from sensor), calibration failure (e.g., CGMcalibration needed or incomplete load sequence), high or low glucoselevels, network (e.g., Bluetooth® or BN-LTE) communication errors,haptic interface errors (e.g., motor failure), speaker errors (e.g.,noise or low volume), medicament cartridge errors (e.g., emptycartridge, cartridge detection error, etc.), and the like. As explainedbelow, each of these errors or conditions may be associated withdifferent severity levels that cause the annunciation of differentalarms.

In some cases, each alarm profile may be associated with a severitylevel or threshold severity level of the alarm. The severity level orurgency level may be associated with how urgently the condition thattriggered the alarm should be addressed or resolved. Further, theseverity level may be associated with an amount of harm that may becaused to a subject when the condition that triggered the alarm is notresolved or is not resolved within a particular time period. The numberof severity levels may vary based on the type of ambulatory medicamentdevice. Generally, there is no limit to the number of severity levels.However, there may be a point of diminishing returns as the number ofseverity levels exceeds a particular number because, for example, it maybe difficult for a user to distinguish between the different numbers ofseverity levels or to identify with which severity level a particularalarm is associated. Thus, the number of severity levels may be limitedto a particular number, such as 0, 3, 5, 6, 9, or some number inbetween. However, it is possible for there to be more than 10 severitylevels.

There may be multiple alarm profiles associated with a severity level.Or each condition of the AMD and/or subject that is associated with thesame severity level may be associated with the same alarm profile.

The AMD may determine a severity of an alarm condition based on thecondition of the ambulatory medicament device and/or the subject thattriggered the alarm condition. In some cases, the ambulatory medicamentdevice may determine the severity of the alarm condition based at leastin part on an alarm profile associated with the alarm condition.

Generally, when the alarm condition does not prevent the AMD fromproviding therapy, the AMD may continue to provide therapy. In someexamples, when the alarm condition interferes with the delivery oftherapy, operation of the AMD may be suspended or partially suspended.Generally, alarm conditions that interfere with the provisioning oftherapy may be associated with a higher severity level. However, somealarm conditions that interfere with the provisioning of therapy may beassociated with lower severity levels. For example, a determination thatthe AMD cannot supply insulin may normally be associated with a highestseverity alarm. But when a user indicates that the site location iscurrently in process of being changed, the alarm condition may beassociated with a lower severity level (e.g., an informational alarmreminding the user that insulin cannot be delivered during site change).In some examples, in response to determining that the severity level ofthe alarm condition matches an unsafe operation (e.g., a condition thatmay cause the AMD to provide doses of the medicament that are above orbelow certain values, or to unreliably determine the subject'scondition), the AMD may suspend delivery of the medicament to thesubject. Once the condition is resolved, the AMD may resume delivery ofmedicament to the subject. When it is determined that the alarmcondition matches a safe operation severity level, the AMD may beconfigured to maintain delivery of medicament to the subject.

Alarm Annunciation

When an alarm condition is satisfied, the alarm annunciation and controlsystem can implement an annunciation pattern or alarm conditionannunciation pattern selected based at least in part on the statusinformation generated by and/or received from the monitoring system. Theannunciation pattern may be selected from a plurality of annunciationpatterns based at least in part on the alarm condition and/or the statusinformation. The annunciation pattern may include one or more differenttext patterns or text information, auditory alarms, visual alarms, orhaptic alarms. Determining whether the alarm condition is satisfied mayinclude comparing one or more status values associated with theambulatory medicament device and/or the subject to one or more alarmthresholds, threshold amounts, or alarm conditions associated with analarm profile.

Upon verifying that an alarm condition associated with an alarm profileor alarm condition is satisfied, the alarm annunciation and controlsystem annunciates the alarm condition. In some cases, at least some ofthe alarm conditions may be associated with a unique annunciationpattern. Advantageously, by having unique annunciation patterns for atleast certain alarm conditions, a user can instantly know the stated ofthe AMD and/or subject based on the annunciation pattern for the alarm.

In some cases, the AMD may have a wireless electronic communicationsinterface that can be used to transmit an alarm signal, statusinformation, alarm condition data, and/or an annunciation pattern to aremote electronic device. In some such cases, the remote electronicdevice may annunciate an alarm when an alarm condition is met. Theremote electronic device may include any device that can receive alarminformation or status information from the AMD. For example, the remoteelectronic device may be a smartphone, smartwatch, smart glasses, alaptop, a tablet, or any other computing device.

In some examples, the alarm system may generate a list of pending alarmconditions that can, for example, be displayed on a touchscreen usingalarm status indicators. In these examples, any time an alarm conditionassociated with an alarm profile is satisfied, the alarm system mayupdate the list of pending alarm conditions by adding the new alarmcondition to the list of pending alarm conditions. In some examples, thelist of pending alarm conditions may include a list of elements (e.g.,icons, text, and the like such as alarm status icons) each indicating analarm condition (e.g., an alarm condition that has been annunciated). Insome examples, the AMD may display an alarm status icon including avisual indication of a count of alarm conditions on the list of pendingalarm conditions.

In certain embodiments, the alarm system may organize an alarm managerlist, notify a user of these alarms, and allow the user to acknowledgeor mute the alarms. In some examples, the alarm manager list may be alist of pending alarm conditions with which the user can interact usinga touchscreen display of the AMD.

In some examples, the list of pending alarm conditions may be sortedaccording to the severity level associated with the alarm conditions. Insome examples, the alarms are categorized numerically in descendingorder with the highest priority fault displayed at the top of the list.In some examples, when the list of pending alarm conditions containsmultiple alarm conditions of the same severity level, the alarmconditions of the same severity level may be displayed in chronologicalorder. In some examples, a level 0 severity may be for a trivial faultthat does not require any action by the user or may be for informationalpurposes only, thus not warranting an alert notification. Acknowledgingthe alarm condition may clear the alarm. In some examples, a level 1severity may be a reminder notification that repeats at a certainfrequency (e.g., every 5 minutes) until acknowledged by the user, whichresults in it being cleared. The annunciation may include a briefvibration and a beep, for example. In some examples, a level 2 severitymay be one relating to an imminent, though non-urgent, loss of systemfunction. Such an annunciation may include 1 brief vibration and 1 beep,for example, and repeating at a certain frequency (e.g., every 5minutes). In various embodiments, alarm annunciation may include analarm annunciation pattern that is aurally or haptically annunciated.The alarm may be snoozed for a period (e.g., 24 hours) when the useracknowledges the fault; however, the user would still need to addressthe situation creating the fault to completely stop the annunciation.

In some examples, a level 3 severity may be for when the system is nolonger fully functional thus requiring user intervention to correct theissue. The annunciation may begin with a base level intensity with threebrief vibrations and three audio beeps, for example, and repeating at acertain frequency (e.g., every 5 minutes). The annunciation escalates ata second frequency, e.g., every 30 minutes, up to a maximum intensitylevel. The escalation may be a change in vibration intensity and/oraudio level, for example. The alarm may be snoozed for a period (e.g.,30 minutes) when the user acknowledges the fault; however, theannunciation when activated may be cleared when the underlying issue isresolved, e.g., glucose level is raised. In some cases, an alarmcondition may change severity levels. For example, a level 3 severitymay be maintained as a level 3 severity or may be lowered to a level 2severity. In some cases, when acknowledging the level 3 fault, the usermay choose to snooze for a short period (e.g., 30 minutes) or a longperiod (e.g., 24 hours). When the user selects to snooze for a shortperiod, the severity level may be maintained at level 3. When the userchooses to snooze for a long period, the severity level may be loweredto level 2. Such an alarm condition may be referred to as having a level2.5 severity.

In some examples, a level 4 severity may be for when the system is nolonger functional and not correctable by the user. The annunciation maybegin with a base level intensity with three brief vibrations and threeaudio beeps, for example, and repeating at a certain frequency (e.g.,every 5 minutes). The annunciation escalates at a second frequency,e.g., every 30 minutes, up to a maximum intensity level. The escalationmay be a change in vibration intensity and/or audio level, for example.The audio and haptic alerts may be cleared when the user acknowledgesthe fault; however, the base alarm remains because the underlyingcondition persists. In some examples, a level 5 severity may be for highpriority alarms per IEC 60901-1-8. The annunciation may begin with abase level intensity with 5 brief vibrations and 5 audio beeps, forexample, and repeating at a certain frequency (e.g., every 5 minutes).The annunciation escalates at a second frequency, e.g., every 30minutes, up to a maximum intensity level. The escalation may be a changein vibration intensity and/or audio level, for example. The alarm may besnoozed for a period (e.g., 30 minutes) when the user acknowledges thefault; however, the annunciation when activated may be cleared only whenthe underlying issue is resolved, e.g., glucose level is raised.

In some examples, the alarm system may annunciate the alarm conditionsvia one or more user interfaces (e.g., a display, a touchscreen display,a speaker, and the like). In some such examples, an alarm may include anaudio alarm, a text message, a graphical message, a text or graphicalmessage with audio, vibrations, flashing light and any combination ofthese. In some examples, the alarm conditions may be transmitted toother devices where, for example, an authorized user (e.g., guardians orparents of the subject), the subject, or an emergency provider can viewthe alarm condition. In some examples, the alarm system may annunciatethe alarm conditions via the user interface module 3218 of theambulatory medical device 600. For example, the alarm condition may beannunciated via one or more user interfaces (e.g., a display, a speaker,and the like). In some examples, the alarm conditions may be transmittedto other devices, via the communication user interface module 3218 ofthe AMD where, for example, an authorized user 3226 (e.g., guardians orparents of the subject), the subject or an emergency provider can viewthe alarm condition. In yet other examples, the alarm annunciation andcontrol system 3212, may establish a direct end-to-end connection with acomputing system (e.g., a cloud computing system) using thecommunication module 3204 and send the alarm condition to the computingsystem through the end-to-end connection.

In some examples, auditory and haptic annunciation of lower urgencyalarms may be muted so as to reduce risk of alert fatigue. Lower urgencyalarms may be alarms that do not require urgent user attention and mayinclude at least alarms with severity levels 0, 1, 2, and 3. In someexamples, higher urgency alarms may be alarms that require urgent userattention and may not be muted, to protect subject safety. In someexamples, each severity level may be predefined as low or high urgency.In some other examples, users may define how low and high urgency alarmsare defined. In some examples, muting an alarm may include suppressingor not providing auditory and haptic annunciation of the alarmcondition. In some examples, the alarm condition may be displayed, suchas on a touchscreen display of the AMD, while auditory and hapticannunciation is not provided.

Based on the severity of the alarm condition and/or the alarm profilecorresponding to the alarm condition, an alarm may be generated and/orannunciated that is associated with the severity of the alarm conditionand/or the type of alarm condition. Different alarm conditions and/oralarm profiles may result in different types of alarms or differentannunciations of the alarm. For example, an alarm associated with thehighest severity level may include an auditory alarm with a loudnessthat exceeds a particular decibel level (e.g., above 70 or 80 decibels),a visual alarm (e.g., a flashing or steady light) with a luminance abovea particular luminance value (e.g., a luminance between 10⁵ or 10⁶candelas per square meter), and/or a vibrational alarm. Further, thealarm associated with the highest severity level may not be snoozed ordismissed, as such alarm conditions may require urgent user attention.In some cases, the alarm associated with the highest severity level maybe snoozed for a shorter time period than alarms of lower severitylevels (e.g., for 5 minutes, for 10 minutes, etc.). An alarm associatedwith a different severity level than the highest severity level mayinclude a different combination of auditory, visual, and vibrationalalarms. Not only may the existence of auditory, visual, and vibrationalalarms differ for different severity levels, but so may thecharacteristics of each of the alarm types. For example, auditory alarmsmay have different sound patterns, loudness, frequencies, etc. Visualalarms may be of different intensity, color, pattern, etc. Vibrationalor haptic alarms may be of different pattern, intensity, etc. Further,an alarm with a different severity level than the highest severity levelmay be permitted to be snoozed or dismisses or snoozed for a longerperiod of time, as such alarm conditions may not require urgent userattention. In some examples, the severity of the alarm condition maydetermine the type of type of the alarm generated (e.g., audio, text,graphical, or any combination of these).

Further, the display of alarm conditions on the user interface mayinclude an icon for each type of alarm condition corresponding to analarm status indicator for that alarm condition. The user interface maydisplay the number of alarm conditions and/or the number of alarmconditions of a particular type or severity level. In some cases, aduplicate alarm may be omitted from the alarm manager list. In somecases, a count of the occurrence of alarms may be increased to reflectthe duplicate alarm. In some cases, a duplicate alarm may result in theannunciation of the duplicate alarm. In some cases, the duplicate alarmis ignored. In some cases, the occurrence of a duplicate alarm may causean escalation of the existing alarm. For example, when an alarmcondition that causes an annunciation of an alarm with a first severitylevel is detected as occurring a second time, the alarm may beannunciated with a second severity level that indicates a greater degreeof severity than the first severity level. It should be understood thatan alarm occurring after an alarm condition is resolved may not beconsidered a duplicate alarm, but instead may be a reoccurrence of thealarm condition and/or an indicator that the resolution for the alarmcondition failed (e.g., an insulin cartridge replacement is faulty or isempty). In some cases, an existing alarm may be escalated when leftunresolved for a period of time. For example, a low battery alarm mayinitially be annunciated with a first severity level but may beannunciated at a higher severity level if the battery is not beingcharged after a certain period of time.

In some cases, the alarm manager list may be observed via a userinterface (e.g., a touchscreen display) when the user interface islocked. In some such cases, further details about the alarms may beaccessible when the user interface is locked. In some cases, in order toaccess more details about the alarms and/or resolve the alarms, it maybe necessary to unlock the user interface unlocked (e.g., by a wakeaction and/or a gesture).

Each of the alarm conditions, or information associated therewith, maybe added to an indicator or user interface (e.g., a list, or other datastructure or user interface element) that may be accessed by a user.This user interface may maintain the alarm condition on the userinterface until the alarm condition is resolved. Further, the alarmconditions may be sorted or ranked based on the severity level of thealarm condition, the time that the alarm condition occurred, whether thealarm condition relates to the subject or the ambulatory medicamentdevice, any combination of the foregoing, or any other factor forsorting or ranking the alarm conditions.

In some cases where the alarm is presented on a display using forexample one or more alarm status indicators, the displayed informationmay include details about what caused the alarm, the severity of thealarm, how to respond to or address the alarm, or any other informationthat may be informative regarding why the alarm was generated and/or howto respond to the alarm. In some cases, the information may provide aworkflow or instructions on how to respond to the alarm. Theinstructions may include a link to a workflow provided by a manufacturerof the ambulatory medicament device or of another entity, such as anentity that provides medicament or site changing kits.

In some cases, different views of an alarm or different informationassociated with the alarm may be provided based on an identity of theuser, or a role of the user, viewing the alarm. For example, a child maybe instructed to contact a parent to address an alarm. But a parent maybe provided with information to resolve the alarm. The parent mayreceive simplified information (e.g., blood glucose level is high) aboutwhat caused the alarm, but a healthcare provider may receive moredetailed information regarding the alarm (e.g., internal controlparameter values, insulin flow rates, curvature of insulin diminishmentpredictions, etc.) that facilitates the healthcare provider caring forthe subject.

The alarm conditions may be displayed on a display of the AMD.Alternatively, or in addition, the alarm conditions may be displayed ona remote display that is separate from the ambulatory medicament device.The remote display may be a display that is authenticated or associatedwith a computing device that is authenticated to access data, such asalarm conditions, from the AMD. In some cases, the alarm manager listmay be presented on a mobile device (e.g., a smartwatch or smartphone)or on a computing device (e.g., a laptop or desktop) that can obtaindata directly or indirectly from the AMD.

In some cases, annunciating the alarm may include contacting amanufacturer and/or user (e.g., a healthcare worker, a parent orguardian, or other registered user). Further, the alarm may includeinstructions on repairing the ambulatory medicament device and/or onaddressing the alarm condition. For example, the alarm may provide auser with instructions to replace the insulin cartridge and how toreplace the insulin cartridge. As another example, the alarm may provideinstructions on how to change the battery of the device or on how tochange a site where the insulin pump connects to the subject. In somecases, the alarm may include one or more operations associated with thealarm. For example, the alarm may trigger reordering of insulin or mayrequest that the user confirm a reorder request to reorder insulin.

Resolving an Alarm

Certain alarms, such as informational alarms, may be dismissible.However, generally the alarm may remain on the alarm list until thecondition that caused the alarm is resolved.

In some cases, a user may be able to acknowledge and/or snooze alarmsvia a user interface. In some examples, in order to acknowledge and/orsnooze alarms, the user may first need to activate the user interface(e.g., by providing a wake action) and then provide a gesture to unlockthe user interface. For example, the user may use the wake button toactivate a touchscreen display and then provide a gesture on the screento unlock display. In some example, the touchscreen display may beconfigured to allow the user or subject to navigate directly to theissue or fault for which an alarm is being delivered. This capabilityprovides the user with access to address the fault causing the alarm sothat it could be corrected thereby stopping the alarm.

In some cases, a user may be able to acknowledge and/or snooze alarmsvia motion sensor. As described herein, the AMD may include a motionsensor that detects motion or acceleration of the AMD or on the AMD(e.g., tapping or shaking gestures). The motion sensor can include anaccelerometer, gyroscope, and/or other electrical or mechanical motionsensors that convert motion or acceleration into electrical signals. Insome examples, the user may tap on the AMD to acknowledge and/or snoozealarms. In some examples, the user may acknowledge and/or snooze alarmsvia the motion sensor without the AMD activating one or more userinterface modules such as the touchscreen display. In some examples, theuser may acknowledge and/or snooze alarms via the motion sensor withoutactivating the user interface (e.g., without providing a wake action).The motion sensor may be configured to detect different tap patterns(e.g., a single tap, a double tap, etc.). Each tap pattern may beassociated with a different function. In some cases, the AMD can includea user interaction sensor which may include any motion sensor(s) and/orany one of the user interface modules such as the touchscreen or thewake interface. The user interaction sensor can convert electrical ormechanical properties of the user into electrical signals. Theelectrical signals from the user interaction sensor can be userinteraction signals. In some cases, user interaction signals canencompass both user input via a touchscreen and user interaction via amotions sensor as discussed herein.

Resolving the alarm may include any action that addresses the conditionthat caused the alarm to be generated. For example, resolving the alarmmay include replacing an insulin cartridge, changing a site where theambulatory medicament device is connected to the subject, charging abattery of the ambulatory medicament device, providing insulin or acounter-regulatory agent to the subject and/or the ambulatory medicamentdevice, or any other action that may be performed to address an alarmcondition. In some cases, the resolution action may be acknowledging thealarm. For example, when the alarm is informational (e.g., to inform theuser that more insulin has been ordered), acknowledging the alarm may bea sufficient resolution action.

In some cases, whether the alarm condition is resolved may depend on anidentity of the user. For example, when a child interacts with an alarmrelated to reordering of insulin, the alarm may remain until a parent orguardian acknowledges the alarm. However, the child may be able tosnooze the alarm. In some cases, a user interface that displays alarmsmay differ based on who is viewing the alarm. For example, a child mayview the alarms, but may not be able to interact with the alarms.However, a parent or guardian may be able to snooze or dismiss an alarm.Further, a child may be instructed to bring the device to a parent oradult to address an alarm. In some cases, the child may be informed ofhow urgently to contact the parent (e.g., contact a parent immediately,within a day, within a week, etc.). Moreover, a designated adult mayseparately be alarmed (e.g., via a text or email alarm). The parent orguardian may receive additional information not provided to the child orsubject (e.g., a link to repair instructions or a workflow to addressthe alarm condition).

In some cases, certain conditions may self-resolve over time. Forexample, a low battery alarm may resolve as the battery is charged. Insuch cases, the alarm may be cancelled automatically as the batterycharge level exceeds a particular threshold. In another example, a lowblood glucose alarm may be resolved once the subject has a meal. Thealarm may be cancelled automatically as the subject's blood glucoselevel rises. Further, in some cases, one or more alarms and/or the alarmlist can be viewed and/or accessed on a home screen, a main screen, orother non-alarm based user interface screen in addition to auser-interface screen designated for display alarms. The alarm list maybe accessed from the ambulatory medicament device and/or a computingsystem in communication with the ambulatory medicament device.

In some cases, the alarm condition may or may not be resolvable when theambulatory medicament device is locked or in a locked state or mode. Thealarm acknowledgement signal may be configured to be detected by themotion sensor and may be one of a gesture input or a touch input, aswill be described hereinafter.

A user may interact with the alarms generated based on the alarmcondition. In some cases, the user can interact with the alarms when theAMD and/or the user interface is unlocked. In some cases, the user caninteract with the alarms to snooze them or to obtain furtherinformation, when the AMD is locked. However, the user may not be ableto dismiss the alarm without unlocking the ambulatory medicament device.The user may not be able to dismiss the alarm without unlocking theambulatory medicament device when the alarm is urgent and requires userattention. Interacting with the alarms may include providing informationassociated with the alarm to a user in response to the user interactingwith the alarm, or an indicator representative of the alarm.

Example AMD with Alarm Management System

FIG. 33 shows a flow diagram illustrating an example procedure that maybe used by the alarm system of an AMD to annunciate an alarm conditionupon receiving a status information that satisfies an alarm condition.In some examples, the alarm system 3202 implements an annunciationprocess by execution of instructions by a processor in CCM of the AMD,where the instructions can be stored in the main memory, storage of theAMD, or in a memory of a connected electronic device or computingsystem.

The alarm system 3202 may receive status information 3302 using themonitoring system interface 3210, one or more device sensors 3208 and/orone or more subject sensors 3216. In some examples, the alarm system3202 determines whether the received status information satisfies analarm condition 3304. In some examples, the alarm condition may be analarm condition in an alarm profile. If the received status informationdoes not satisfy an alarm condition, no action may be taken 3306. If thereceived status information satisfies an alarm condition, the alarmsystem may determine whether the alarm condition is already present inthe list of pending alarm conditions or not 3308. If the alarm conditionis not present in the list of pending alarm conditions, the alarm systemmay add the alarm condition to the list of pending alarm conditions3310. Next the alarm system, may determine the severity of the alarmcondition 3312. Based on the determined level of severity, the alarmsystem 3202 can select an annunciation pattern 3314 and annunciate thealarm condition using the selected annunciation pattern 3316. If thealarm condition is present in the list of pending alarm conditions, atblock 3318, the alarm system may select an annunciation pattern andannunciate the alarm condition using the selected annunciation pattern3320. In some examples, the annunciation pattern selected at block 3318,may be an annunciation pattern that is different than the previouslyused annunciation patterns for the alarm condition. In some suchexamples, the annunciation pattern selected at block 3318, may beselected based on number of times that the same alarm condition issatisfied by a received status information. The process of the alarmdetection and control function may repeat each processing cycle so longas the ambulatory medical device is in use. In some examples, after analarm is annunciated, the alarm system may wait for user acknowledgmentof the alarm. If the user acknowledges the alarm, the system proceeds toperform alarm processing. However, if the user fails to acknowledge thealarm, the annunciation continues and may escalate depending on thelevel of the alarm.

As mentioned above, the alarm conditions may be categorized based andannunciated based on their severity level. In some examples, the alarmsare categorized numerically in descending order with the highestpriority fault displayed at the top of the list.

In some examples, a level 0 severity, may be for a trivial fault thatdoes not require any action by the user thus not warranting an alarmnotification. In some other examples, a level 1 severity may be aninformational type notification that repeats at a certain frequency(e.g., every 30 minutes) until acknowledged by user which results in itbeing reset. The annunciation may include a brief vibration and a beep,for example. In some examples, a level 2 severity, may be one relatingto an imminent loss of system function. Thus, such an annunciation mayinclude two brief vibrations and two beeps, for example, and repeatingat a certain frequency (e.g., every 30 minutes). Thus, the user wouldstill need to address the situation creating the fault to completelystop the annunciation. In some other examples, a level 3 fault may befor when the system is no longer fully functional thus requiring userintervention to correct the issue. The annunciation may begin with abase level intensity with three brief vibrations and three audio beeps,for example, and repeating at a certain frequency (e.g., every 5minutes). The annunciation escalates at a second frequency, e.g., every30 minutes, up to a maximum intensity level. The escalation may be achange in vibration intensity and/or audio level, for example. Theescalation may be cleared to base level when the user acknowledges thefault; however, the base alarm remains if underlying condition persists.Thus, the user would still need to address the situation creating thefault to completely stop the annunciation. In some examples, a level 4severity, may be for when the system is no longer functional and notcorrectable by the user. The annunciation may begin with a base levelintensity with three audio beeps, for example, and repeating at acertain frequency (e.g., every 5 minutes). The annunciation escalates ata second frequency, e.g., every 30 minutes, up to a maximum intensitylevel. The escalation may be a change in audio level, for example. Theescalation may be cleared when the user acknowledges the fault; however,the base alarm remains because the underlying condition persists. Insome other examples, a level 5 severity, may be for high priority alarmsper IEC 60601-1-8. The annunciation when activated may be cleared whenthe underlying issue is resolved, e.g., glucose level is raised.

Additional embodiments relating to determining a severity of an alarmcondition and annunciating the alarm based at least in part on theseverity of the alarm condition that can be combined with one or moreembodiments of the present disclosure are described in U.S. ProvisionalApplication No. 62/911,017, which was filed on Oct. 4, 2019 and istitled “ALARM SYSTEM AND METHOD IN A DRUG INFUSION DEVICE,” thedisclosure of which is hereby incorporated by reference in its entiretyherein for all purposes.

Non-Critical AMD Condition Management

In some cases, a condition may occur that impacts the operation of theambulatory medicament device. This condition may be associated with theability of the ambulatory medicament device to operate as intended bythe manufacturer, a subject receiving therapy from the ambulatorymedicament device, and/or user (e.g., healthcare provider, parent, orguardian of the subject). In some cases, the condition or malfunction ofthe ambulatory medical device may prevent the ambulatory medical devicefrom providing therapy to the subject. In other cases, the condition ormalfunction may permit, at least for a period of time, the ambulatorymedical device to continue providing at least partial therapy to thesubject. In either case, it is generally desirable to generate an alertto inform the subject and/or one or more users of the condition of theambulatory medical device and/or the subject. Moreover, it is desirableto track the alert until the condition that caused the alert isresolved. Further, it is desirable to issue different types of alertsfor different conditions to enable a subject or user to easilydistinguish the severity of the condition that triggered the alert.

In many cases, if the nature of the alert is non-critical, it may besafer to continue the underlying therapy and notify the user of thecondition than to cease therapy. In some such cases, the best responseto a problem with the device for a subject is to notify the devicemanufacturer, or other user that can address the problem, while thesubject continues to receive therapy until a replacement device can beobtained or a repair can be made.

Additionally, alert fatigue can be an issue with medical devices due toexcessive alerts which do not necessarily require user interaction.Alert fatigue can be dangerous because it can lead users to ignoreserious alerts or alerts that require action in the short term.

The method described herein may be performed by an AMD (e.g., by one ormore processor of the AMD) to detect device malfunctions for the AMD andthat can generate alerts corresponding to the ambulatory medical deviceand prioritize the alerts to enable the subject or user to quickly andeasily determine whether the device malfunction will impact therapy,should be addressed in the short-term (e.g., immediately, in 1-2 hours,within the day, etc.), and/or can be addressed at the subject'sconvenience (e.g., within a month, or more). In some cases, the methodmay be used by other systems.

In certain embodiments, the system disclosed herein can detect acondition in which the ambulatory medical device does not meet amanufacturer's specification (e.g., a failure of a haptic annunciator, aBluetooth® radio malfunction, glucagon or insulin runs out, there is amedicament delivery malfunction, a touchscreen failure, etc.). In somecases, there can be several tiers of critical and/or non-criticalfaults. If it is determined that the underlying condition is notsufficient to stop therapy (e.g., delivery of insulin is not stopped),the fault may be deemed non-critical. In some cases, the fault may notbe a fault of the device, but may be indicative of required maintenance(e.g., recharge battery indicator, order more medicament indicator,etc.). The condition may be annunciated to the user with appropriateinstructions (e.g., call manufacturer for replacement medicament orparts) for addressing the fault or issue.

After the annunciation is acknowledged, the alert may be re-annunciatedas a reminder at some later period in time (e.g., the alert may bere-annunciated daily at 4:00 PM or on Saturdays at noon). The length oftime between annunciations may depend on the severity of the fault. Insome cases, the re-annunciation cannot be stopped by the user, but mayonly cease if the underlying condition is resolved.

The method may include detecting a condition of the ambulatory medicaldevice. The condition of the ambulatory medical device may be determinedby one or more sensors of the ambulatory medical device. Further, thecondition of the ambulatory medical device may be determined by thepresence or absence of one or more errors when performing one or morefunctions of the ambulatory medical device. For example, if theambulatory medical device fails to establish a communication connectionwith a control system or a data storage system, it may be determinedthat there is a possible malfunction with the ambulatory medical device.As another example, if the ambulatory medical device fails to delivermedicament or detects an error when attempting to deliver medicament,there may be a malfunction with the medicament pump. In some cases, thecondition of the ambulatory medical device may be determined based onone or more configuration values being outside a normal operating range.For example, if the speed of delivery of medicament is faster or slowerthan a configured operating range, then it may be determined that thereis a malfunction with the medicament pump or a connection with amedicament delivery tube (e.g., a catheter).

The method may include comparing the detected condition of theambulatory medical device to a set of normal operating parameters. Theset of normal operating parameters may be the specifications set by themanufacturer for when the ambulatory medical device is operating asintended by the manufacturer. In some cases, the normal operatingparameters may be associated with a range of values. For example, theoperating parameter for a speed of medicament delivery may be associatedwith a range of speeds, which may vary based on user settings,medicament type, site location of medicament delivery, or manufacturingtolerances, among other parameters. Comparing the detected condition ofthe ambulatory medical device to the set of normal operating parametersmay include comparing each operating parameter in the specification to acorresponding detected operating parameter of the ambulatory medicaldevice. The ambulatory medical device may generate a user alert based onthe determined condition of the ambulatory medical device. For example,the AMD may generate an alert when the detected condition of theambulatory medical device does not satisfy a set of normal operatingparameters.

The method may further include determining whether the detectedcondition satisfies a minimum set of operating parameters. In somecases, the minimum set of operating parameters may match the normaloperating parameters. However, typically the minimum set of operatingparameters differ from the normal operating parameters. The minimumoperating parameters may include the minimum specifications, minimumparameters, or minimum condition required by the ambulatory medicaldevice to maintain or continue providing therapy to the subject. Inother words, the minimum operating parameters are the operatingparameters sufficient to provide therapy. However, the minimum operatingparameters may not be sufficient to enable all features of theambulatory medical device. For example, the minimum operating parametersmay permit the ambulatory medical device to deliver insulin to thesubject, but may not be sufficient to deliver the insulin at a normaldelivery speed for the particular ambulatory medical device. As anotherexample, the minimum operating parameters may permit the delivery oftherapy, but may not be sufficient to track a log of therapy or totransmit a therapy log to another computing system. In some cases, thenormal operating parameters and/or minimum operating parameters may bespecified by a subject or healthcare provider (e.g., the minimum amountof medicament that is to be provided in each bolus may be specified by ahealthcare provider). In some cases, the normal or minimum operatingparameters may be modified.

When it is determined that the condition of the ambulatory medicaldevice satisfies at least the minimum operating parameters, theambulatory medical device may be configured to maintain delivery oftherapy to the subject. Maintaining delivery of therapy may includemaintaining therapy at the same rate, at a reduced rate (e.g., providingonly basal therapy and therapy responsive to a meal announcement), or ata minimum maintenance rate (e.g., providing only basal insulin).Advantageously, the ability of the ambulatory medical device todistinguish between a minimum set of operating parameters and a normalset of operating parameters enables an ambulatory medical device with amalfunction to continue providing therapy, which sometimes includeslife-saving treatment, to a subject until the ambulatory medical devicecan be repaired or until the condition of the device worsens to a pointwhere the minimum operating parameters cannot be maintained. In somecases, the ambulatory medical device may temporarily maintain deliveryof therapy. Temporarily maintaining therapy may provide a subject timeto address the issue that caused the ambulatory medical device to notsatisfy the normal operating parameters before the subject loses accessto therapy. In some cases, the ambulatory medical device temporarilymaintains therapy until the device condition makes it no longer possibleto maintain therapy.

FIG. 34 is a block diagram illustrating the interconnection amongmodules and procedures in AMD involved in monitoring the condition ofthe AMD and generating an alert when a device malfunction is detected.In some examples, the condition of AMD may include the status of themodules and components of the AMD, such as AMD modules and sensors 3404and/or operation of modules and procedures of the AMD. In someembodiments, the alert system may be implemented as a set of alertcontrol procedures 3408 in the control and computing module 610 (CCM) ofthe AMD. The alert control procedures 3408, may be implemented asinstructions stored in a memory of CCM (e.g., the main memory 616) andexecuted by a hardware processor 614 to generate an alert upon detectionof a malfunction of the ambulatory medicament device. In some cases, thehardware processor may be a hardware processor of the ambulatorymedicament device that controls medicament delivery. In other cases, thehardware processor of the monitoring system may be a separate hardwareprocessor.

In some examples, the alert control procedures 3408 may include amonitoring interface 3414, an operation monitoring procedure 3412 andalert generation procedure 3416. The monitoring interface 3414 maymonitor and evaluate the condition of the AMD and/or the subject atleast partially based on the information received from the operationmonitoring procedure 3412 and device sensors 3410. In some examples, thedevice sensors may be configured to track the status of the componentsor the modules of the ambulatory medicament device and the operationmonitoring procedure 3412 may be configured to monitor the operation ofthe modules and other procedures. In some examples, the detected of theAMD may be provided to the alert generation procedure monitoringinterface. The alert generation procedure 3416 may compare the detectedcondition of the AMD with a set of normal operating parameter. In someexamples, the alert generation procedure may also determine whether thedetected condition of the AMD satisfies a minimum set of operatingparameters. In some examples, if it is determined that the detectioncondition of the AMD does not satisfy the normal operating parameters,the alert generation procedure may generate an alert. In some examples,the alert may be transmitted to the user interface module 3406 anddisplayed on a display of the AMD (e.g., a touchscreen display). In someother examples, once an alert is generated the AMD may establish aconnection (e.g., a wireless connection) with another device. This otherdevice may include a local device (e.g., a laptop, smartphone, orsmartwatch of the user) or a computing system of a cloud-based service.In some such examples, the alert may be transmitted by the communicationmodule 3402 to the computing systems where it may be displayed on userinterface associated with the computing system. In some cases, theadditional device may receive data from the ambulatory medical deviceenabling it to monitor the condition of the ambulatory medical device.

The type of the alert, and the frequency at which the alert is repeated,or whether an alert is dismissible or not, may be determined by thealert generation procedure based on the detected condition of the AMDand the alert information stored in a memory of the AMD. In someexamples, the alert information may be provided by the subject, anauthorized user, or a healthcare provider. In some other examples, thealert information may be stored in the AMD at time of manufacturing.

In some examples, upon determination that the detected AMD conditiondoes not satisfy a set of normal operating parameters, the alertgeneration procedure may cause the medicament delivery interface, suchas the therapy delivery module 606, to stop therapy delivery or modifyone or more delivery parameters (e.g., therapy delivery rate). In someexamples, upon determination that the detected AMD condition does notsatisfy a set of normal operating parameters, but satisfies a set ofminimum operating parameters, the therapy delivery may be maintained ata normal rate.

The alert may include any type of alert. For example, the alert may be avisual alert (e.g., a light or changing light), an audible alert (e.g.,a beep or series of beeps), a haptic or vibration alert, an email alert,a text alert, or any other type of alert. Different device conditionsmay be associated with or may trigger different alerts. Thus, the useralert may enable the user to determine the device condition of theambulatory medical device based on the alert. For example, an indicationthat the ambulatory medical device failed to deliver a medicament maytrigger one type of alert while an indication that the ambulatorymedical device has below a particular level of medicament available maytrigger a different alert. In some cases, the user alert is dismissibleand/or may be snoozed by the user. In other cases, such as when theambulatory medical device fails to satisfy a set of minimum operatingparameters, the user alert may not be dismissible or cannot be snoozed.

A dismissible alert may be scheduled to repeat on a particular scheduleuntil an alert modification condition occurs. The frequency with whichthe dismissible alert repeats may depend on the severity of thecondition or the particular operating parameters that do not satisfynormal or minimum operating parameters. More urgent device conditionsmay result in alerts that repeat more frequently. Further, alerts mayvary based on when the condition was detected, the time of day, or thedetected activity of a subject (e.g., sleep, abnormal activity, orelevated activity, such as exercise). Similarly, the snooze options mayvary for different alerts or any of the aforementioned conditions. Insome cases, the ambulatory medical device may escalate an alert if itdetects that the condition of the ambulatory medical device has becomemore critical.

The alert frequency may be for a static time period (e.g., every 5hours) or may ramp towards more frequency (e.g., every 5 hours for 1 to3 reminders, every 4 hours for 3 to 6 reminders, etc.), or may changebased on time of day (e.g., snooze alerts during sleeping hours fornon-urgent alerts), etc.

The alert modification condition may include any action that causes theoperating parameters of the ambulatory medical device to return tonormal operating parameters. For example, the alert modificationcondition may be a repair or replacement of a faulty component. In somecases, the alert modification condition may include an acknowledgementof the alert. In other cases, the alert modification condition mayinclude a worsening of the ambulatory medical device condition. In suchcases, the modification to the alert may include the substitution of thealert to a different alert that indicates a different or more seriouscondition of the ambulatory medical device. For example, an urgentcondition may become critical if the detected malfunction is addressedafter generating certain number of alerts. When an urgent conditionbecomes critical, it may trigger a different alert type (e.g., a loudersound, or brighter image) and/or escalation in the alert frequency. Forexample, the audible alert may become louder and may be combined with avibration alert from a haptic annunciator. Moreover, if the conditionreaches a critical state, the ambulatory medical device may ceaseproviding therapy to the subject.

In some cases, generating the alert may further include contacting amanufacturer and/or healthcare provider (e.g., clinician). Further,generating the alert may include ordering replacement parts. In somecases, the alert may instruct a subject or user on how to repair theambulatory medical device.

Once the malfunction is addressed, the ambulatory medical device isrepaired, or the condition that caused the alert is resolved, a user maypermanently (or until the next time a device condition triggers thealert) dismiss the alert. Alternatively, or in addition, the ambulatorymedical device may automatically dismiss the alert if it senses that thedevice condition that caused the alert has been resolved. In some cases,the ambulatory medical device may periodically recheck the devicecondition to determine whether the alert condition has been resolved.

In some cases, the manufacturer or healthcare provider may remotelyclear or stop an alert using, for example, an NB-LTE connection. In somecases, only the manufacturer and/or healthcare provider can clear orstop the alert. Further, in some cases, a manufacturer and/or ahealthcare provider may notify a user (e.g., a subject, or parent orguardian) of an issue or impending issue with the ambulatory medicaldevice. The notification may be received by the ambulatory medicaldevice via the NB-LTE connection. Alternatively, or in addition, thenotification may be received via a computing device, such as asmartphone or laptop.

FIG. 35 is a flow diagram illustrating an example procedure that may beused by the alert system of an AMD to monitor the operation of an AMDand generate alerts when a device malfunction is detected. In someexamples, the alert system continuously monitors the status of allmodules and components associated with AMD as well as the operation ofall modules and procedures of the AMD. When a device condition isdetected 3502, the alert system may determine whether the detecteddevice condition satisfies a set of normal operating parameters 3504. Ifit is determined that the detected device condition satisfies a set ofnormal operating parameters, the alert system takes no action andcontinuous monitoring the AMD. If it is determined that the devicecondition does not satisfy a set of normal operating parameters, thealert system determines whether the detected device condition satisfiesa set of minimum operating parameters. If, at block 3506, it isdetermined that the device condition does not satisfy a set of minimumoperating parameters, the alert system may send a signal to the therapydelivery module to stop delivery of therapy to the subject 3508, andimmediately generate a critical user alert 3512 indicating thatimmediate action is required. In some examples, upon generation of acritical alert the alarm system of the AMD, may contact a healthcareprovider or certified user (e.g., parent or guardian of the subject) andalso send the critical alert to one or more computing devices (e.g.,laptop, cell phone, personal computer, and the like) of the healthcareprovider or certified user. If, at block 3506, it is determined that thedevice condition satisfies a set of minimum operating parameters, thealert system may maintain the delivery of therapy to the subject 3510and generate a user alert 3514. In some such examples, the alert systemmay maintain the delivery of the therapy at rate associated with thedetected condition of the AMD (e.g., normal rate or minimum maintenancerate) until an alert modification condition is detected 3516. Upondetection of an alert modification condition 3516, the alert system maydetermine whether the new device condition satisfies a normal setparameters 3518. If, at block 3518, it is determined that the new devicecondition satisfies a set of normal operating parameters, the alertsystem may resume the normal operation of the AMD 3520 (e.g., deliverthe therapy at a normal rate). If at block 3518, it is determined thatthe new device condition does not satisfy a set of normal operatingparameters, the alert system may determine whether the new devicecondition satisfies a minimum set parameters 3522. If, at block 3522, itis determined that the new device condition satisfy a set of minimumoperating parameters. The alert system may maintain or modify the rateof therapy delivery according to the new device condition 3526 andgenerate a user alert 3530 according to the according to the new devicecondition. If, at block 3522, it is determined that the new devicecondition does not satisfy a set of minimum operating parameters, thealert system may send a signal to the therapy delivery module to stopdelivery of therapy to the subject block 3524, and immediately generatea critical user alert 3528 indicating that immediate action is required.In some examples, upon generation of a critical alert the alarm systemof the AMD, may contact a healthcare provider or certified user (e.g.,parent or guardian of the subject) and also send the critical alert toone or more computing devices (e.g., laptop, cell phone, personalcomputer, and the like) of the healthcare provider or certified user.

Managing Doses of Glucose Control Agents

Ambulatory medical devices allow subjects the freedom to treatthemselves while being mobile. Self-managed medical treatment comes withinherent risks to the subject.

An automated blood glucose control system may automatically provideinsulin and/or a counter-regulatory agent (e.g., Glucagon) to a subjectto help control the blood glucose level of the subject. Generally, acontrol algorithm is implemented by an automated blood glucose controlsystem (BGCS) to determine when to deliver one or more glucose controlagents and how much agent to provide to the subject. Further, thecontrol algorithm may control both an ongoing or periodic delivery ofinsulin (e.g., a basal dose), and a correction bolus that may beprovided to adjust a subject's blood glucose level to within a desiredrange. The control algorithm may use blood glucose level readingsobtained from a sensor, such as a continuous glucose monitoring (CGM)sensor, that obtained automated blood glucose measurements from thesubject. Moreover, in some cases, the control algorithm may deliver abolus of insulin in response to an indication of a meal to be consumedor being consumed by the subject.

Insulin may be administered subcutaneously into blood of a subject.There is often a delay between when the insulin is provided and when theamount of insulin in the subject's blood plasma reaches maximumconcentration. This amount of time may vary based on the type of insulinand on the physiology of the particular subject. For example, with afast-acting insulin, it may take approximately 65 minutes for a bolus ofinsulin to reach maximum concentration in the blood plasma of thesubject. For some other types of insulin, it may take anywhere from 3-5hours to reach maximum concentration in the blood plasma of the subject.Accordingly, the blood glucose control system may implement a predictivealgorithm that implements a bi-exponential pharmacokinetic (PK) modelthat models the accumulation of insulin doses in the blood plasma of thesubject. The blood glucose control system may modify its predictionsbased on the type of insulin, one or more blood glucose readings, and/orcharacteristics of the subject.

In some cases, a subject may receive a manual bolus of insulin ormedicament. For example, a user (e.g., healthcare provider, parent, orguardian) or subject may inject a dose of insulin into the subject. Asanother example, the user or subject may manually direct the automatedblood glucose control system to provide a bolus of insulin to thesubject.

It is generally undesirable to have too much insulin. An excess ofinsulin can lead to Hypoglycemia. As described above, it may take timefor insulin to reach maximum concentration in the blood plasma of thesubject. Thus, a blood glucose level reading from a sensor may notimmediately, or even after a particular period of time, reflect theamount of insulin within a subject. Thus, a manual bolus of insulin maynot be detected by the automated blood glucose control system. As aresult, if the automated blood glucose control system is operatingduring delivery of a manual bolus or is configured to operate on thesubject prior to blood glucose level readings reflecting the effect ofthe manual bolus on the subject, the automated blood glucose controlsystem may unnecessarily administer additional insulin to the subjectpotentially leading to hypoglycemia.

The present disclosure relates to an automated blood glucose controlsystem configured to provide automatic delivery of glucose controltherapy to a subject and receive information about manual glucosecontrol therapy provided to the subject. Using the received informationabout the manual glucose therapy, the automated blood glucose controlsystem can adjust the blood glucose control algorithm to account for themanual dosing of insulin (or counter-therapy agents). The manual glucosecontrol therapy may be provided by injection therapy, or it may beprovided by an insulin pump.

In some cases, the automated blood glucose control system may receive anindication of insulin or medicament to administer to a subject in placeof an automatically calculated dose of insulin. For example, theautomated blood glucose control system may receive an indication that asubject is consuming or will consume a meal. The indication may includea type of meal to be consumed (e.g., breakfast, lunch, or dinner) and anestimate of the quantity of food or carbohydrates to be consumed (e.g.,less than usual, a usual amount, more than usual, 30-40 grams ofcarbohydrates, 45-60 grams of carbohydrates, etc.). Based on theindication, or meal announcement, the automated blood glucose controlsystem may calculate an amount of insulin to administer to the subject.The calculation may be based on an insulin to carbohydrate ratioprovided by a clinician and/or determined by the automated blood glucosecontrol system. Moreover, the calculation may be based at least in parton a history of blood glucose level measurements for the subject whenconsuming particular meals.

The calculated amount of insulin for the meal announced by the user maybe presented to the user. The user (e.g., the subject) may modify theamount of insulin to administer. For example, the user may determinethat for the size meal the subject is consuming or planning to consume,more or less insulin should be administered. In such cases, the user maymodify the calculated insulin dosage to match the user's determinationof the amount of insulin to administer. In some cases, the automatedblood glucose control system may modify its control algorithm based onthe user's input. Thus, future meal announcements may result in acalculation of insulin that satisfies the subject's insulin needs and/orpreferences.

In some cases, the indication of an amount of a manual bolus may bereceived by a user entering a numerical value (e.g., an amount ofinsulin, a number of carbohydrates, or another calculation) associatedwith administering insulin. As described above, the automated bloodglucose control system may automatically-calculate a meal dose ofinsulin and present it to a user via a user interface where a user mayenter the manual bolus information. At the time of making the mealannouncement, the user may have an option to enter the manual bolus. Themeal controller of the blood glucose pump can provide a recommendationagainst the manual entry if there is a prior history of online operationor a basis for making the recommendation.

The information may be received from a user via a user interface. Thisuser interface may be provided by the automated blood glucose controlsystem. Alternatively, or in addition, the user interface may begenerated by another device, such as a laptop or desktop, a smartphone,a smartwatch, or any other computing device that can communicate viawired or wireless communication with the automated blood glucose controlsystem. The information may include one or more of: an indication ofdelivery of a manual bolus (e.g., via injection therapy), an amount ofthe manual bolus, a type of the insulin (or other medicament), a timewhen the manual bolus was delivered, a general location that the manualbolus was administered to the subject (e.g., back, stomach, arm, leg,etc.), a reason for the manual bolus (e.g., a meal, a maintenance dose,a blood glucose level reading, in advance of exercise, etc.), and anyother information that may be useable by the blood glucose controlsystem in controlling the blood glucose level of the subject.

Advantageously, in certain embodiments, providing manual dosinginformation to the automated blood glucose control system can help theblood glucose control system maintain the blood glucose level of thesubject within a desired range when the automated features of the bloodglucose control system are active or operational. For example, if theautomated blood glucose control system determines from a CGM sensorreading that a subject's blood glucose level is high, the automatedblood glucose control system might normally administer a bolus ofinsulin. However, if the automated blood glucose control system receivesan indication that a manual bolus of insulin was administered recently(e.g., within the past thirty minutes), the automated blood glucosecontrol system may reduce or not administer a bolus of insulin, therebypreventing a Hypoglycemic event. In some such cases, the automated bloodglucose control system may continue monitoring the blood glucose levelof the subject and may administer additional insulin at a later time ifthe blood glucose level readings do not reflect an expected bloodglucose level based on the reported manual bolus of insulin.

In some cases, it may be unnecessary to receive an indication of themanual bolus because, for example, a user may cause the automated bloodglucose control system to provide the manual bolus. In such cases, theautomated blood glucose control system may track the amount of insulindelivered and the timing of the administering of the bolus. To track themanual bolus, the automated blood glucose control system may store theinformation associated with the manual bolus in a therapy log.Accordingly, when the automated blood glucose control system isoperating in an automatic mode, the automated blood glucose controlsystem can access the therapy log to determine whether any manual boluswere administered and, if so, the timing and amount of the manual bolus.

In some cases, the automated blood glucose control system may model thediminishing of insulin, or other medicament, in the blood plasma overtime based on the information associated with the manual bolus. Modelingthe diminishing of medicament over time may be used to estimate a futureeffect of the medicament previously administered. In some cases, themodel may account for previously administered medicament by theautomated blood glucose control system. Further, in some cases, themodel may account for physiological characteristics of the subject, suchas the subject's weight or an input parameter related to the subject'sweight (e.g., body mass index). Moreover, the model may account forperfusion over time of the medicament bolus from a subcutaneous infusionsite into the blood plasma of the subject. Further, the automated bloodglucose control system may model an accumulation of insulin, model timecourse of activity of insulin, or model a finite rate of utilization ofinsulin.

Based on the model, the automated blood glucose control system mayadjust the automated administering of insulin, or other medicament whenoperating in an automatic mode. Further, the automated blood glucosecontrol system may operate the administering of medicament (e.g., bycontrolling a medicament pump) based on a glucose level of the subjectand the modeled concentration of medicament in the subject.

In some cases, the automated blood glucose control system may confirmthat the manual bolus was delivered to the subject. The confirmation maybe determined based at least in part on whether blood glucose levelreadings by the CGM sensor match or are within a threshold levelanticipated by the automated blood glucose control system based on themanual dosing information. Alternatively, or in addition, the automatedblood glucose control system may request, via a user interface, that auser confirm that the manual bolus was delivered. In cases where themanual bolus in delivered by the automated blood glucose control system,a user may be requested to confirm the administering of the manual bolusby using a particular gesture or sequence of interactions with a userinterface (e.g., a touchscreen) of the automated blood glucose controlsystem or of a device (e.g., laptop or smartphone, etc.) thatcommunicates with the automated blood glucose control system.

As previously described, in some cases, the information relating to themanual bolus may include an amount of insulin and a reason the manualbolus was administered (e.g., for a meal of a particular size). In somesuch cases, the automated blood glucose control system may determine anamount of insulin the automated blood glucose control system wouldadminister in an automatic operating mode based on the manual dosinginformation if the manual bolus had not been supplied. If the automatedblood glucose control system determines it would have supplied adifferent quantity of the medicament, and if the difference exceeds athreshold, the automated blood glucose control system may adjust a bloodglucose control algorithm to account for the difference. For example,the automated blood glucose control system may change the operatingsetpoint or range of insulin the automated blood glucose control systemattempts to maintain in the subject. As another example, the automatedblood glucose control system may supplement the manual bolus withadditional insulin to account for an under-administering of insulin ormay reduce a subsequent dosage of insulin to account for anover-administering of insulin.

As previously indicated, the automated blood glucose control system maymaintain a therapy log of manual insulin therapy. This therapy log maybe maintained based on the use of the automated blood glucose controlsystem to provide a manual bolus or based on information provided by theuser based on manual administering of insulin (e.g., via injection). Themanual boluses may be supplied when the automated blood glucose controlsystem is not operating, is not operating in an automatic mode, or isnot connected to the subject. Once the automated blood glucose controlsystem is connected to the subject and is configured in automatic mode,the automated blood glucose control system may determine therapy, ifany, to provide to the subject based on a combination of the therapy logand the glucose control algorithm implemented by the automated bloodglucose control system.

The automated blood glucose control system may generate a dose controlsignal based on the determined therapy. This dose control signal may besupplied to a medicament pump, which may control delivery of themedicament (e.g., insulin) to the subject.

In some cases, a user may control whether the automated blood glucosecontrol system is operating in a manual mode or an automatic mode byinteracting with a user interface of the automated blood glucose controlsystem or of a device that communicate with the automated blood glucosecontrol system. The user interaction may include any type of userinteraction with a user interface. For example, the user interaction mayinclude interaction why physical buttons or interactions with atouchscreen including gestures or taps on the touchscreen.

Additional embodiments relating to managing meal medicament doses andmanual dosing that can be combined with one or more embodiments of thepresent disclosure are described in U.S. Provisional Application No.62/911,143, which was filed on Oct. 4, 2019 and is titled “SYSTEM ANDMETHOD OF MANAGING MEAL DOSES IN AN AMBULATORY MEDICAL DEVICE,” thedisclosure of which is hereby incorporated by reference in its entiretyherein for all purposes.

A system of one or more computers can be configured to performparticular operations or actions by virtue of having software, firmware,hardware, or a combination of them installed on the system that inoperation causes or cause the system to perform the actions. One or morecomputer programs can be configured to perform particular operations oractions by virtue of including instructions that, when executed by dataprocessing apparatus, cause the apparatus to perform the actions. Onegeneral aspect includes a method including: providing an option to auser to select between receiving medicament using a manual deliverycomponent or an automated delivery system. The method also includesreceiving, by the automated delivery system, subjective informationregarding the activity or action that may alter the blood-glucose level.The method also includes receiving, by the manual delivery component, anamount of the medicament to be infused. The method also includes storinga time and the amount of medicament that is infused into the automateddelivery system that controls blood glucose level. Other embodiments ofthis aspect include corresponding computer systems, apparatus, andcomputer programs recorded on one or more computer storage devices, eachconfigured to perform the actions of the methods.

Implementations may include one or more of the following features. Themethod where the automated delivery system modifies medicament deliverybased on the time and the amount of medicament that was received fromeither the manual delivery component or the automated delivery system.The method where the manual delivery component includes a keypad whichallows the user to type in the dosage amount of the desired medicament.The method where providing the option to select is provided prior to auser performing the activity that may alter the blood-glucose level. Themethod where the activity that may alter the blood-glucose levelincludes of consuming food or exercising. The method where thesubjective information regarding the activity of consuming food includesthe approximate relative size of the food that is to be digested. Themethod where the approximate relative size of the food is compared tothe recommended meal doses for the user and depending on whether theapproximate relative size is the same, larger, or smaller than therecommended doses, the model predictive control component is able todetermine the actions that is required to regulate the glucose level ofthe blood. The method where the subjective information regarding theactivity of exercising includes the intensity and the duration of theexercise. The method where the intensity and the duration of theexercise is compared to the recommended intensity and duration, anddepending on whether it is the same, larger, or smaller than therecommended intensity and duration, the automated delivery system isable to determine the actions that is required to regulate the glucoselevel of the blood. Implementations of the described techniques mayinclude hardware, a method or process, or computer software on acomputer-accessible medium.

One general aspect includes a system having a medical device configuredto provide an option to a user to select between receiving medicamentusing a manual delivery component or an automated delivery system. Thesystem also includes automated delivery system configured to receivesubjective information regarding the activity that may alter theblood-glucose level. The system also includes a manual deliverycomponent configured to receive an amount of the medicament to beinfused. The system also includes where the medical device storing atime and the amount of medicament that is infused into an automateddelivery system that controls blood glucose levels. Other embodiments ofthis aspect include corresponding computer systems, apparatus, andcomputer programs recorded on one or more computer storage devices, eachconfigured to perform the actions of the methods.

Upon utilizing an ambulatory medical device to request for a therapychange, users may have different preferences. Therefore, it is desirablefor modern technology, specially the ambulatory medical devices to beequipped with optionality features. These optionality features mayfulfill the different preferences of the users and subjects. Theoptionality features may allow users to control the therapy changes moreclosely and may allow them to be more engaged with the medicalassistance of the ambulatory medical device.

In order to fulfill the variety of preferences, an ambulatory medicaldevice needs to provide options which allows the user to either manuallyrequest the amount of the desired medicament or chose an automateddelivery system that automatically delivers the right amount of themedicament at the right time without further assistance. For the manualcomponent, the user may personally input the desired amount on a keypadthat is provided by the medical device. The medical device furtherconfirms and delivers the requested medicament. After the medicament isinfused through a manual delivery component, the data is stored into amodel predicative control component which is further used to control andregulate the blood glucose level. However, if the user decides to usethe automated delivery system, the user must provide subjectiveinformation regarding the activity or the action that may alter theblood-glucose level. For example, if the blood-glucose level changingactivity is consuming food, the user must provide the time and thedosage amount of the food that is going to be digested. This informationis tied to the automated delivery system, and the subjective informationis further stored into a model predicative control component.

Embodiments described herein include an ambulatory medical device thathas a keypad which allows a user to type in a dose of insulin orglucagon to be administered to a user. A user may wish to receive asingle dose of insulin prior to consuming food and decide how muchinsulin need to be administered. In other embodiments, the user maychoose to receive a burst of glucagon due to low blood sugar because ofphysical activities. Embodiments may include the options for manualinputs of medicament and automated delivery system of medicament. Invarious implementations, the automated delivery system of medicament isdriven by the blood glucose level or related trends. Embodiments hereinaddress a problem that may arise when the user has just received amanual dose and has switched on the automated delivery system. In suchcases, the automated delivery system may be made aware of all manualmedicament infusion amounts and the timing of such infusions.Accordingly, the manual delivery component may inform the automateddelivery system upon delivering any medicament the type of medicamentdelivered, the amount of medicament and the timing of the medicamentdelivered. By having the above information, the automated deliverysystem may determine the amount of medicament that is the user's bloodstream and adjust the automated delivery of medicament and the timing ofthe automated delivery. Accordingly, embodiments are directed to allowsfor a risk-free transition from the manual delivery component and theautomated delivery system.

Differences from other system may include that the manual delivery maybe tied to an automated delivery system, the dose input from the user isthen stored into the MPC algorithm (Model Predictive Control) instead ofthe meal delivery algorithm and is handled by the MPC algorithm. Otherembodiments may include selection being able to have a relativisticalgorithmically tuned value. Other embodiments may include a learningalgorithm that includes a usual size meal or larger size meal or smallsize meal. Embodiments may include correlating the manual inputs toasking the user what the size of the meal was and learning how theinsulin affects the user. Embodiments may include correlating the manualinputs to asking the user what activity the user performed and learninghow the glucagon affects the user for a particular activity.

BGCS with Manual Dose Management

FIG. 36 illustrates a schematic of the therapy change delivery system3600 in an ambulatory medical device 3602 that allows the user thechoice of receiving manual delivery of medicament or automated deliveryof medicament. Moreover, the therapy change delivery system 3600 allowthe user to transition between the manual mode and the automated modewith ease. The therapy change delivery system 3600 includes theambulatory medical device 3602, a signal processing component 3604, auser 3606, a therapy delivering component 3608, a therapy change input3610, input components 3612, activity change component 3614, and atherapy change delivery 3616. When the user intends to receive a therapyfrom an ambulatory medical device 3602, the user 3606 may initiate atherapy change input 3610 to request the manual or automated medicament.

The ambulatory medical device 3602 is any medical device that a user3606 may carry around and use with the approval of a medicalprofessional. There are many different types of ambulatory medicaldevices 3602. In one embodiment, the ambulatory medical device 3602 isan insulin and/or glucagon infusion device for user 3606 that have typeI diabetes. Ambulatory medical devices 3602 allow users 3606 the freedomto receive medical care in any setting at their convenience. However,the drawback of using an ambulatory medical device 3602 could be theuser 3606 making mistakes when the user is away from the medicalprofessionals. One possible issue may be caused the user 3606 switchesfrom a manual delivery mode to an automated delivery mode when theautomated delivery mode is unable to determine the amount of medicamentin the user's blood stream. Embodiments are directed to the manualmedicament delivery information being provided to the automatedmedicament delivery system so that it can adjust its operations based onthe current and future medicament in the user's blood stream. In somecases, such as the embodiment where the ambulatory medical device 3602is an insulin and/or glucagon infusion device, doing automated deliveryof medicament can be problematic.

The ambulatory medical device 3602 includes a signal processingcomponent 3604, a therapy delivering component 3608, and inputcomponents 3612. The signal processing component 3604, therapydelivering component 3608, and input components 3612 may be physicallyconnected, wirelessly connected, connected via a cloud-based computersystem, or connected in any other way.

The signal processing component 3604 is a computing system that performsthe computing functions for the ambulatory medical device 3602. Thesignal processing component 3604 includes a processor, memory, andstorage. The signal processing component 3604 may be a single computingsystem or may be made up of several computing systems. The signalprocessing component 3604 may perform the computing functions for asingle ambulatory medical device 3602 or many ambulatory medicaldevices. The signal processing component 3604 receives signals from thetherapy delivering component 3608 and from the input components 3612.The signal processing component 3604 also transmits signals to thetherapy delivering component 3608 and the input components 3612. Signalsof the therapy change input 3610, the therapy change delivery 3616, andall steps of the activity change component 3614 may be received ortransmitted by the signal processing component 3604.

The user 3606 is any individual that uses the ambulatory medical device3602. In one embodiment the user 3606 is an individual with diabetesthat requires a periodic infusion of insulin or glucagon to maintainhealthy blood sugar levels. In various embodiments, the ambulatorymedical device 3602 infuses insulin or glucagon into the user 3606. Theuser 3606 may transport the ambulatory medical device 3602. Thus, as theuser 3606 moves around, there is a danger that the user 3606 willinadvertently activate input in the ambulatory medical device 3602 thatinitiates a therapy change input 3610.

The therapy delivering component 3608 provides medicaments to the user3606. Signals received from the signal processing component 3604 areexecuted by the therapy delivering component 3608 to change therapy suchas starting, modifying, or stopping a therapy. The therapy deliveringcomponent 3608 may have a computing component for interpreting andexecuting instructions from the signal processing component 3604. Thus,the therapy delivering component 3608 can follow a program that iscontrolled by the signal processing component 3604. In one embodiment,the therapy delivering component 3608 is one or more infusion pumps. Aninfusion pump is capable of delivering fluids at varying rates to a user3606. The infusion pump may deliver any fluid, including medicaments.The infusion pump may be connected to a user 3606 through any means. Inone example, the infusion pump is connected to the body through acannula. In an exemplary embodiment, the therapy delivering component3608 is an insulin infusion pump. Also, in an exemplary embodiment, thetherapy delivering component 3608 is an insulin and glucagon infusionpump. Signals received from the signal processing component 3604 may beinterpreted by an insulin and glucagon pump to start, stop, or changethe rate of insulin and glucagon being delivered into a user 3606.

In an exemplary embodiment, the therapy delivering component 3608 is anelectrical stimulation device. An example of an electrical stimulationdevice is a cardiac pacemaker. A cardiac pacemaker stimulates thecardiac muscle to control heart rhythms. Instructions received from thesignal processing component 3604 may be interpreted by a cardiacpacemaker to start stimulating a cardiac muscle, stop stimulating acardiac muscle, or change the rate of stimulation of a cardiac muscle.Another example of an electrical stimulation device is a deep brainstimulator to treat Parkinson's disease or movement disorders.Instructions received from the signal processing component 3604 may beinterpreted by the deep brain stimulator to start, stop, or modify thestimulation of the brain.

The therapy change input 3610 is an input provided by the user 3606 tochange a therapy that is currently being delivered to the user 3606. Thechange of therapy may be to start a therapy, modify a therapy, or cancela therapy. There are many types of possible therapy changes, and thetypes of therapy changes are dependent on the type of ambulatory medicaldevice 3602. In one embodiment, the ambulatory medical device 3602 is aninsulin or glucagon infusion device. However, there are many possibleembodiments of ambulatory medical devices 3602 for the disclosed subjectmatter. The therapy change input 3610 in an insulin or glucagon infusiondevice may be an instruction, that when executed, causes the insulin orglucagon infusion device to start infusing an amount of insulin orglucagon into the user 3606. Alternatively, the therapy change input3610 may be an instruction to modify the rate of insulin or glucagoninfusion into the user 3606. The therapy change input 3610 may also bean instruction to cancel insulin or glucagon infusion into the user 3606from the insulin or glucagon infusion device. In an exemplaryembodiment, the ambulatory medical device 3602 is an electrical implant,that when operated, stimulates a part of the body. An example is anelectrical brain implant for users 3606 with Parkinson's disease or forpain management. The implementation of the therapy change can be tomodify the rate of electrical stimulation to the body.

The therapy change delivery 3616 is the performance, by the ambulatorymedical device 3602, of the therapy change input 3610 that was verifiedby the 3614. The therapy change that is delivered by the therapy changedelivery 3616 corresponds to the therapy change selection made by theuser 3606. In one embodiment, the ambulatory medical device 3602 alertsthe user 3606 that it is performing a therapy change delivery 3616. Inan example of various embodiments, the ambulatory medical device 3602displays the therapy change during the therapy change delivery 3616. Anynumber of details of the therapy change may be displayed during thetherapy change delivery 3616. As shown in FIG. 43, a simple message of“Delivering” may be displayed during the therapy change delivery 3616.Alternatively, more exact details, such as “Delivering 2 units ofinsulin” or “Delivering insulin at 2 units per minute” may be displayed.In another example, the ambulatory medical device 3602 plays a soundeffect during the therapy change delivery 3616. In an exemplaryembodiment that is shown in FIG. 43, the therapy change delivery 3616may be canceled by an input by the user 3606. The input to cancel atherapy change delivery 3616 may be any input such as a wake signalinput or a series of touch inputs such as a gesture.

The input components 3612 allow the user 3606 to interact with andcontrol the ambulatory medical device 3602. The amount of control that auser 3606 has may vary based on the type of ambulatory medical device3602 and the user 3606. For example, an ambulatory medical device 3602that delivers pain medication may allow the user more control than anambulatory medical device 3602 that controls heart rhythms. In anotherexample. a user 3606 that is a young child (less than about 10, 11 or 12years) may be allowed less control over an ambulatory medical device3602 than a user 3606 that is a teen or an adult. The input components3612 include a wake button 3626, a touchscreen display 3628, and analphanumeric pad 3630.

The wake button 3626 is activated by a user 3606 to create a wake signalinput to unlock an ambulatory medical device 3602. The wake button 3626may be any input button. In one embodiment, the wake button 3626 is acapacitive button that detects a change in capacitance. The wake button3626 may have a computing component for interpreting and executinginstructions from the signal processing component 3604. Thus, the wakebutton 3626 can follow a program that is dictated by the signalprocessing component 3604.

The touchscreen display 3628 may display a therapy change user interfacefor the user 3606 and receive user 3606 inputs on the touchscreendisplay 3628 input surface. Inputs on the touchscreen display 3628 maybe registered by any touch technology including, but not limited tocapacitive and resistive sensing. The touchscreen display 3628 may be apart of a mobile computing device, such as a cellular phone, tablet,laptop, computer, or the like. The touchscreen display 3628 may have acomputing component for interpreting and executing instructions from thesignal processing component 3604. Thus, the touchscreen display 3628 canfollow instructions that are directed by the signal processing component3604. To receive input, the touchscreen display 3628 may displaybuttons, alphanumeric characters, symbols, graphical images, animations,or videos. The touchscreen display 3628 may display an image to indicatewhen the ambulatory medical device 3602 is locked or inaccessible viathe touchscreen display 3628. The touchscreen display may receive theseries of inputs that make up the first gesture and the second gesture.

The alphanumeric pad 3630 registers numerical inputs, alphabeticalinputs, and symbol inputs. The alphanumeric pad 3630 includes amultitude of keys corresponding to numerical, alphabetical, and symbolinputs. The alphanumeric pad 3630 may have a computing component forinterpreting and executing instructions from the signal processingcomponent 3604. Thus, the alphanumeric pad 3630 can follow instructionsthat are dictated by the signal processing component 3604. Thealphanumeric pad 3630 may be configured to provide haptic feedback fromits keys. The alphanumeric pad or pads 3630 may have any number of keysand any number of characters and may span multiple screens that the user3606 can toggle between in order to find all of their sought-aftercharacters. In one embodiment, the wake button 3626 is incorporated intothe alphanumeric pad 3630. In various embodiments, the wake button 3626may be any one or more keys of the alphanumeric pad 3630. In anexemplary embodiment, the alphanumeric pad 3630 is displayed as part ofthe touchscreen display 3628. Characters from the alphanumeric pad 3630may be used as input for the wake signal input, first gesture, therapychange selection, and second gesture. In an exemplary embodiment, thefirst gesture and/or second gesture are created by enteringpredetermined characters on the alphanumeric pad 3630.

The activity change component 3614 may be part of a specialized softwarethat is executed on an ambulatory medical device or include aspecialized hardware that performs the various functions described here.The activity change component 3614 may receive inputs from the userregarding weather the user is about to conduct activities that willchange the blood glucose of the user. For example, the user may provideinput using the input components 3612 that the user is about to performexercise that may lower their blood sugar or eat a meal that willincrease their blood sugar. Upon receiving the activity change from theinput components 3612, the activity change component 3614 offers theuser the option via the mode controller 3620 to select between theautomated delivery system 3618 or the manual delivery component 3622. Asshown in FIG. 36, the manual delivery system may inform the automateddelivery system 3618 and the model predictive control component 3624regarding any manual medicament deliveries of insulin or glucagon.

In various embodiments, the user may choose the dosage amount, the drugtype (insulin or glucagon; fast or slow acting) and the time of thedelivery and the manual delivery component 3622 may receive suchinformation and deliver the medicament(s) accordingly. In oneembodiment, the manual delivery component 3622 may inform the automateddelivery system 3618 and the model predictive control component 3624regarding the drug type (insulin or glucagon; fast or slow acting) andthe time of the delivery.

When the user activates the automated delivery system 3618, the datafrom previous manual medicament infusions can be readily available sothat the automated delivery system 3618 may be able to determine howmuch medicament is still in the user's blood stream. The automateddelivery system 3618 may make that determination by tracking the finiterate of utilization of infused insulin by the subject based on the timeand amount of any manual medicament infusions reported to the automateddelivery system 3618.

FIG. 37 is a flow chart of a process 3700 detailing a medicamentselection process, according to an exemplary embodiment. In step 3702,the medical device provides an option to a user to select betweenreceiving medicament using a manual delivery component or an automateddelivery system. By using the mode controller 3620, the user can selectthe method for the therapy change request between manual deliverycomponent and the automated delivery system.

In step 3704, the medical device may receive subjective informationregarding the activity or action that may alter the blood-glucose level.Subjective information may include the size of the meal and/or the typeof physical activity. In step 3706, the manual delivery component mayreceive an amount of the medicament to be infused. The medicament may bea plurality of hormones, including but not limited to, glucagon orinsulin. At step 3708, the medical device may store a time and theamount of medicament that was infused into the automated deliverycomponent that controls the blood glucose level. The systems that aredisclosed in FIG. 36 will be utilized to accomplish each and every stepfrom steps 3702, 3704, 3706 and 3708.

FIG. 38 is another flow diagram of a process 3800 for providing optionsfor meal dosage selection or physical activity of the user on anambulatory device. Embodiments described herein include an ambulatorymedical device that has a keypad which allows a user to type in a doseof insulin or glucagon to be administered to a user. A user may wish toreceive a single dose of insulin prior to consuming food and decide howmuch insulin need to be administered. In other embodiments, the user maychoose to receive a burst of glucagon due to low blood sugar because ofphysical activities. Embodiments may include the options for manualinputs of medicament and automated delivery system of medicament. Invarious implementations, the automated delivery system of medicament isdriven by the blood glucose level or related trends. Embodiments hereinaddress a problem that may arise when the user has just received amanual dose and has switched on the automated delivery system. In suchcases, the automated delivery system may be made aware of all manualmedicament infusion amounts and the timing of such infusions.Accordingly, the manual delivery component may inform the automateddelivery system upon delivering any medicament the type of medicamentdelivered, the amount of medicament and the timing of the medicamentdelivered. By having the above information, the automated deliverysystem may determine the amount of medicament that is the user's bloodstream and adjust the automated delivery of medicament and the timing ofthe automated delivery. Accordingly, embodiments are directed to allowsfor a risk-free transition from the manual delivery component and theautomated delivery system.

At block 3802, the user may inform the activity change component 3614that the user is about to engage in activities that may alter theblood-glucose level of the user. The mode controller 3620 may beactivated at decision block 3804 and ask whether the user wants to usethe manual delivery component 3806 or the automated system 3810. If theuser chooses to use the manual delivery component 3806 and the userprovides an input to infuse medicament, the ambulatory device 3602 maydelivery the medicament to the user. Upon the manual delivery processcompletion, the manual delivery component 3806 may inform at least oneof the model predictive control component 3808 and the automateddelivery system 3810 regarding the type of medicament, amount ofmedicament and the time when the medicament was delivery. The predictivecontrol component 3808 and automated delivery system 3810 may trackthese manual infusions of medicament and determine that based on therate of decay or the half-life of the medicament the total amount ofmedicament that remains in the user's blood stream at a particular timeor a period of time. Accordingly, when the automated delivery system3810 is activated by the user, the automated delivery system 3810 maychange its medicament infusion based on the medicament that remains inthe user's blood stream after a manual infusion by the user.

Differences from other system may include that the manual delivery maybe tied to an automated delivery system, the dose input from the user isthen stored into the MPC algorithm (Model Predictive Control) instead ofthe meal delivery algorithm and is handled by the MPC algorithm. Otherembodiments may include selection being able to have a relativisticalgorithmically tuned value. Other embodiments may include a learningalgorithm that includes a usual size meal or larger size meal or smallsize mean. Embodiments may include correlating the manual inputs toasking the user what the size of the meal was and learning how theinsulin affects the user. Embodiments may include correlating the manualinputs to asking the user what activity the user performed and learninghow the glucagon affects the user for a particular activity.

FIG. 39 illustrates a plurality of screens 3900 that may be produced bythe ambulatory medical device 3602. The plurality of screens 3900demonstrates a process that a user may take in order to enter mealdoses. When the activity change component 3614 is activated, the entermeal doses screen 3902 may be displayed. Once the screen 3902 isdisplayed, a warning text may be displayed for the user to ensuresafety. The warning text states that entering a dose may be unsafe andthe device will not adapt its meal doses. This warning text cautions theuser of the risks that may be involved in the process of using theambulatory medical device 3602. After a user acknowledges the warningsign and choses to proceed, a password screen 3904 may be displayed.Once the password screen 3904 is displayed, a keypad is provided for theuser to enter a predetermined sequence of numbers to ensure that theuser is the actual registered user of the ambulatory medical device3602. When the ambulatory medical device 3602 receives the correctpredetermined password from the user, the enter meal doses officialscreen 3906 and meal doses official screen 3908 may be displayed. Theuser may decide to access the advanced screen 3912, and upon doing so,the advanced screen 3912 will allow the user to double check the CGMInsulin levels and change the speed of the of the insulin pump. Inscreen 3906 and screen 3908, the user is provided the option to have themeal keypad on or off. If the user selects to have the keypad on, thenan option may be provided for the user to choose the max dose limit. Ifthe user decides to choose the max dose limit, the official max doselimit screen 3910 is displayed, where the user may enter up to 10 unitsof the dose. The provided number of units is then stored in the modelpredictive control component 116 for further regulation of the bloodglucose level.

FIG. 40 illustrates a plurality of screens 4000 that may be produced bythe ambulatory medical device 3602. Upon activating the ambulatorymedical device (e.g., the ambulatory medical device 500, 600, or 3602)the initial menu screen 4002 may be displayed. In the menu screen 4002,options regarding functionalities of the ambulatory medical device 3602is provided. The list of functionalities may cover all the aspects ofthe ambulatory medical device 3602. The user may access and control manyaspects of the device by choosing the setting option. The setting optionwill allow the user to further assess and regulate the adjustablefunctionalities of the ambulatory medical device 3602. Upon selectingthe setting option, the setting screen 4004 may be displayed and theuser may select the advanced setting option. Upon selecting the advancedoption, the advanced setting screen 4006 is displayed, and the user isprovided the option to double check the CGM insulin levels and changethe speed of the of the insulin pump. The user may speed up the processor slow down the process depending on the regulation stats that areprovided by the model predictive control component 3624.

FIG. 41 illustrates a plurality of screens 4100 that may be produced bythe ambulatory medical device 3602. The plurality of screens 4100 is theprocess that a user may take in order to enter meal announcements. Thehome screen 4102 provides information and stats regarding the cartridgeof the ambulatory medical device 3602. The user may select the mealbutton with or without an installation of a new cartridge. If a userselects the meal button without installing a new cartridge, theambulatory device 3602 will display the warning screen 4106, where theuser is warned that the insulin cartridge is empty, and the devicefurther advises the user to change the cartridge. However, if a newcartridge is already installed and the food button is pressed, theambulatory medical device 3602 will display the carbs screen 4104, wherethe user is provided the option to choose a meal dose option. The carbsscreen 4104 allows the user to provide subjective information regardingthe food that is to be digested. This subjective data provided by theuser is further stored in the model predictive control component 3624for further regulation of the blood glucose level.

FIG. 42 illustrates a plurality of screens 4200 that may be produced bythe ambulatory medical device 3602. The plurality of screens 4200demonstrates the process of the user being alerted about the emptycartridge and having the option to replace the cartridge and furtherenter the meal doses. Warning screen 4202 alerts the user that theinsulin cartridge is empty and the fact that it needs to be replaced.Upon replacing the cartridge, screens 4204 and 4206 will be displayed.Screen 4204 is initially displayed, and a user may enter a specifieddose for each meal on a numerical pad. Upon inserting a numericalspecified dose, screen 4206 is displayed where a next button is providedfor the user to further complete the therapy change. The numericalspecified dose is further stored in the model predictive controlcomponent 3624 for further regulation of the blood glucose level.

FIG. 43 illustrates a plurality of screens 4300 that may be produced bythe ambulatory medical device 3602. Upon selecting the delivery request,a user may cancel the delivery of the medicaments prior to thecompletion of the delivery. The ambulatory medical device 3602 displaysa countdown prior to delivery. The initial countdown screen 4302 isproceeded by the secondary countdown screen 4306. During these countdownscreens, a cancel button is provided for the user to cancel the therapychange. During the initial countdown screen 4302 or the secondarycountdown screen 4306, the user may cancel the delivery at any time. Byswiping the cancel button, the user may officially stop the delivery ofthe therapy change. If the user does not cancel, the therapy change maybe delivered successfully. Furthermore, the time and the amount of thetherapy change delivery is stored in the model predictive controlcomponent 3624 for further regulation of the blood glucose level.However, if the user decides to cancel the delivery, the delivery willbe canceled and the screen 4304 will be provided. Once the deliverycancelation is requested and the screen 4304 is displayed, upon pressingthe ok button, the ambulatory medical device 3602 will display a lockscreen 4308 and take the time to officially cancel the therapy changerequest.

FIG. 44 is a block diagram illustrating a computer system 4400 that maybe implemented in the various embodiments in the described subjectmatter. The computer system 4400 includes a processor 4402 (e.g.,electronic or hardware processor), main memory 4404, storage 4406, a bus4408, and input 4410. The processor 4402 may be one or more processors.The processor 4402 executes instructions that are communicated to theprocessor through the main memory 4404. The main memory 4404 feedsinstructions to the processor 4402. The main memory 4404 is alsoconnected to the bus 4408. The main memory 4404 may communicate with theother components of the computer system through the bus 4408.Instructions for the computer system 4400 are transmitted to the mainmemory 4404 through the bus 4408. Those instructions may be executed bythe processor 4402. Executed instructions may be passed back to the mainmemory 4404 to be disseminated to other components of the computersystem 4400. The storage 4406 may hold large amounts of data and retainthat data while the computer system 4400 is unpowered. The storage 4406is connected to the bus 4408 and can communicate data that the storageholds to the main memory 4404 through the bus 4408.

The processor 4402 may be any type of general-purpose processorincluding, but not limited to a central processing unit (“CPU”), agraphics processing unit (“GPU”), a complex programmable logic device(“CPLD”), a field programmable gate array (“FPGA”), or anapplication-specific integrated circuit (“ASIC”). Some embodiments ofthe computer system 4400 in the ambulatory medical device 102 features aCPU as the processor 4402. However, embodiments may be envisioned forthe computer system of the ambulatory medical device 102 thatincorporate other types of processors 4402.

The main memory 4404 can be any type of main memory that can communicateinstructions to the processor 4402 and receive executed instructionsfrom the processor 4402. Types of main memory 4404 include but are notlimited to random access memory (“RAM”) and read only memory (“ROM”). Insome embodiments, the computer system 4400 incorporates RAM as the formof main memory 4404 to communicate instructions to the processor 4402and receive executed instructions from the processor 4402. Otherembodiments may be envisioned that incorporate other types of mainmemory 4404 in the computer system 4400.

The storage 4406 can be any type of computer storage that can receivedata, store data, and transmit data to the main memory 4404 via the bus4408. Types of storage 4406 that can be used in the computer system 4400include, but are not limited to, magnetic disk memory, optical diskmemory, and flash memory. In some embodiments, flash memory is used asthe storage 4406 in the computer system 4400 of the ambulatory medicaldevice 102. Other embodiments that use other types of storage 4406 forthe computer system 4400 may be envisioned.

The bus 4408 connects the internal components of the computer system4400. The bus 4408 may include a multitude of wires that are connectedto the components of the computer system 4400. The wires of the bus 4408may differ based on the components of the computer system 4400 to whichthe bus 4408 connects. In various embodiments, the bus 4408 connects theprocessor 4402 to the main memory 4404. In various embodiments, theprocessor 4402 is directly connected to the main memory 4404.

The input 4410 of the computer system 4400 may include a touchscreendisplay 4412, an alphanumeric pad 4414, and buttons 4416. Thetouchscreen display 4412 may both produce output and accept input. Thetouchscreen display can generate user input signals corresponding userinput. A touchscreen controller can receive user the user input signals.The touchscreen display can display user interface screens generated bycomputer system 4400 as discussed herein (for example, the criticalstatus information interface illustrated in FIG. 55). The bus 4408 maybe coupled to the touchscreen display 4412 to produce visual output. Thetouchscreen display 4412 may also accept input via capacitive touch,resistive touch, or other touch technology. The input surface of thetouchscreen display 4412 can register the position of touches on thesurface. Some types of touchscreen display 4412 can register multipletouches at once. The alphanumeric pad 4414 may include a multitude ofkeys with numerical, alphabetical, and symbol characters. Signals fromthe alphanumeric pad 4414 may be communicated by the bus 4408 to themain memory 4404. Keys of the alphanumeric pad 4414 may be capacitive ormechanical. In some embodiments, the alphanumeric pad 4414 is displayedon the touchscreen display 4412. Buttons 4416, such as the wake buttonor interface, may be capacitive, mechanical, or other types of inputbuttons. The wake interface may include one or more of the embodimentsdescribed herein with respect to the wake interface 3220 of FIG. 32.

The input 4410 may be a user interface module as disclosed with respectto the user interface module 3218 of FIG. 32. The user interface modulemay include any type of user interface controller for providing a userinterface as discussed herein. The user interface may be provided on adisplay 4412 of the computer system 4400 (e.g., an AMD 100), or may betransmitted to a display of an electronic device in communication withthe computer system 4400 (e.g., an AMD 100). In some cases, the userinterface controller may be a touchscreen controller that is configuredto output display signals configured to generate one or more userinterface screens on a touchscreen. Further, the touchscreen controllermay be configured to receive user input signals corresponding to userinteraction with the touchscreen.

Occlusion Detection

When a subject is receiving therapy, often there may be an occlusion(e.g., a kink or obstruction in the medicament delivery path). Theocclusion may be detected by a system and/or the medicament pump.However, sometimes a false signal may be detected that would otherwisecause a system to slow and/or stop therapy delivery. Systems and methodsdescribed herein can be effective at reducing the likelihood ofneedlessly slowing and/or stopping therapy delivery by better detectingfalse occlusion signals. The systems and methods can protect the userfrom dangerous occlusions while minimizing false alarms of occlusions.False alarms may be the result of one or more signals, such as anelectrical signal (e.g., increased current), an increased frictionwithin the system, or some other signal.

FIG. 45A illustrates a schematic of an example ambulatory medicamentpump 4500 that is configured to maintain delivery of therapy to asubject after determining that a possible occlusion exists in amedicament delivery system. The medicament delivery system can includethe ambulatory medicament pump 4500 and/or other components describedherein, such as elements described with respect to FIG. 29, FIG. 33(deleted), FIG. 34, and FIG. 36. The ambulatory medicament pump 4500includes a medicament reservoir 4502, a pump motor 4508, anon-transitory memory 4510, and an electronic hardware processor 4512.The ambulatory medicament pump 4500 can include a medicament passageway4506 configured to couple to a medicament delivery interface 4504. Themedicament passageway 4506 may include a delivery tube operativelycoupled between the medicament reservoir 4502 and an infusion site or asubcutaneous depot of the subject and may be configured to deliver themedicament through the skin of the subject. The medicament deliveryinterface 4504 may be at the infusion site or a subcutaneous depot ofthe subject, and of the subject where medicament is delivered to thesubject as therapy.

The ambulatory medicament pump 4500 is any medical device that thesubject may carry around and use with the approval of a medicalprofessional. The ambulatory medicament pump 4500 may correspond toand/or share certain functionality with one or more devices describedherein, such as the ambulatory medical device 3602 or therapy deliveringcomponent 3608 described above with respect to FIG. 36. There are manydifferent types of ambulatory medicament pumps 4500. In one embodiment,the ambulatory medicament pump 4500 is an insulin and/or glucagoninfusion device for subjects that have type I diabetes. Ambulatorymedicament pumps 4500 allow subjects the freedom to receive medical carein any setting at their convenience.

However, the ambulatory medicament pump 4500 could malfunction duringuse by the subject in the absence of a medical professional. Forexample, an interference or occlusion may develop within the ambulatorymedicament pump 4500 and/or associated elements. An occlusion maydevelop in a variety of possible scenarios. For example, a tube (e.g.,the medicament passageway 4506) may become kinked, the pump motor 4508may become jammed or obstructed (e.g., from sand or debris), themedicament reservoir 4502 may become jammed or obstructed, etc. When anocclusion alert is identified, this could be an indication of an actualocclusion that requires attention and perhaps repair by a professional.Additionally or alternatively, the occlusion alert may suggest thatthere is an anomaly or other condition in the therapy delivery and/orfunctionality of the ambulatory medicament pump 4500 but not that anocclusion is present. For example, the anomaly could correspond to afalse alarm. The false alarm could be due to one or more conditions,such as an increase of pressure in the medicament reservoir 4502, anincreased pressure on a pump piston operatively coupled to pump motor4508, slippage of the piston, a spike or drop in electrical currentdelivered to the pump motor 4508, and/or something else.

The ambulatory medicament pump 4500 can include a wireless datainterface may be physically connected with the ambulatory medicamentpump 4500, wirelessly connected, connected via a cloud-based computersystem, or connected in any other way.

The processor 4512 is part of a computing system that performs thecomputing functions for the ambulatory medicament pump 4500. Theprocessor 4512 may be a single processor or may be made up of severalprocessors. The processor 4512 may perform the computing functions for asingle ambulatory medicament pump 4500 or many ambulatory medicamentpumps. The processor 4512 receives signals from the pump motor 4508and/or from the wireless data interface. The processor 4512 alsotransmits signals to the pump motor 4508 and/or from the wireless datainterface.

The subject is any individual that uses the ambulatory medicament pump4500. In some embodiments the subject is an individual with diabetesthat requires a periodic infusion of insulin or glucagon to maintainhealthy blood sugar levels. In various embodiments, the ambulatorymedicament pump 4500 infuses insulin or glucagon into the subject. Thesubject may transport the ambulatory medicament pump 4500. Thus, as thesubject moves around, there is a danger that the subject will be awayfrom medical professionals who can provide any necessary therapy if anocclusion develops within the ambulatory medicament pump 4500.

The ambulatory medicament pump 4500 can include therapy deliverycomponents, such as the pump motor 4508. The therapy delivery componentsmay include one or more elements of an infusion pump, such as the pumppiston, a cannula, and/or other components as described herein. Thetherapy delivery components provide medicaments to the subject. Signalsreceived from the processor 4512 are executed by the therapy deliverycomponents, such as the pump motor 4508, to change therapy such asstarting, modifying, or stopping a therapy. The therapy deliverycomponents may include a computing component for interpreting andexecuting instructions from the processor 4512. Thus, the therapydelivery components can follow a program that is controlled by theprocessor 4512.

The therapy change delivery 3616 is the performance, by the ambulatorymedicament pump 4500, of the therapy change input 3610 that was verifiedat the therapy delivering component 3608. The therapy change that isdelivered by the therapy change delivery 3616 corresponds to the therapychange selection made by the subject. In some embodiments, theambulatory medicament pump 4500 alerts the subject that it is performinga change in therapy delivery. In an example of various embodiments, theambulatory medicament pump 4500 displays the therapy change during thechange in therapy delivery. Any number of details of the therapy changemay be displayed during the change in therapy delivery, such as shown inFIG. 43 and described above.

The ambulatory medicament pump 4500 may include a user interface, suchas a graphical user interface. The user interface may be operativelycoupled to the ambulatory medicament pump 4500 via, for example, thewireless data interface. The user interface can include a touchscreendisplay. The touchscreen display may display an occlusion detectioninterface for the subject and/or receive subject inputs on the occlusiondetection interface. Inputs on the touchscreen display may be registeredby any touch technology including, but not limited to capacitive andresistive sensing. The touchscreen display may be a part of a mobilecomputing device, such as a cellular phone, tablet, laptop, computer, orthe like. The touchscreen display may have a computing component forinterpreting and executing instructions from the processor 4512. Thus,the touchscreen display can follow instructions that are directed by theprocessor 4512. To receive input, the touchscreen display may displaybuttons, alphanumeric characters, symbols, graphical images, animations,or videos. In some embodiments, the user interface is not a touchscreendisplay. The user interface may include one or more mechanical buttons.The user interface may include an alert generator, such as a lightemitter, a speaker, a haptic feedback system, or other sensory alertsystem.

The ambulatory medicament pump 4500 may be configured to detect possibleocclusions and probable occlusions. A possible occlusion suggests thatan occlusion may exist but that more information is needed to adequatelydetermine that an occlusion probably exists. A probable occlusionsuggests that the ambulatory medicament pump 4500 or other systemelement may take action based on the detection that a probable occlusionexists.

To determine whether an occlusion is possible or probable, theambulatory medicament pump 4500 may undertake one or more of a varietyof actions. For example, the system may be configured to detect one ormore fluid delivery parameters associated with the medicament deliverysystem. The fluid delivery parameter can include an electricalparameter, such as a current supplied by the pump motor 4508, anelectrical resistance associated with the pump motor 4508, or a voltageassociated with the pump motor 4508. The fluid delivery parameter caninclude any other detectable parameter, whether via a sensor (e.g., apressure sensor, a flow rate sensor, or the like) or via some other way.For example, the fluid delivery parameter can include a fluid flow rateand/or a fluid flow acceleration through the cannula, through themedicament reservoir 4502, through the medicament passageway 4506,through the medicament delivery interface 4504, or through some otherportion of the ambulatory medicament pump 4500 or of the medicamentdelivery system. The fluid delivery parameter can include a pressure onthe pump motor 4508, on the medicament reservoir 4502, on the medicamentpassageway 4506, on the medicament delivery interface 4504, or on someother component or components of the medicament delivery system. In somecases, the pressure on or inside any components of the medicamentdelivery system may be obtained by a pressure sensor (e.g., a pressuresensor integrated with the component). For example, the acceptablepressure within the ambulatory medicament pump 4500 may be around 2-3pounds per square inch (psi), and the fluid delivery parameter may be apressure threshold of any pressure above a threshold pressure level(e.g., about 15 psi).

The ambulatory medicament pump 4500 may determine that a fluid deliveryparameter satisfies an initial occlusion condition. The first initialocclusion condition may indicate that a possible occlusion exists thatinterferes with delivery via the medicament delivery system. Because itmay be advantageous to continue the delivery of medicament to thesubject when only a possible occlusion exists (as opposed to a probableocclusion), in response to the determination that the fluid deliveryparameter satisfies the initial occlusion condition, the ambulatorymedicament pump 4500 can maintain delivery of therapy to the subject.Maintaining delivery of therapy can include providing therapy at thesame rate as prior to the determination that the initial fluid deliveryparameter satisfies the initial occlusion condition. In someembodiments, maintaining delivery may mean providing therapy at adifferent rate from prior to the determination. For example, maintainingdelivery may include providing delivery at a different speed (e.g., halfspeed). In some embodiments, in response to the determination that thefluid delivery parameter satisfies the initial occlusion condition, theambulatory medicament pump 4500 may modify an attribute of the deliveryof therapy while maintaining delivery of the therapy to the subject. Forexample, the attribute may include a delivery speed, a deliveryinterval, a delivery pressure, or impulse, etc. In some examples, theambulatory medicament pump 4500 can begin injecting the fluid slowly andthen inject quickly to invoke a jerk. This may be helpful at clearing apossible occlusion. Other examples are possible. For example, theambulatory medicament pump 4500 may pulse the delivery of delivery oftherapy at regular and/or irregular intervals.

In some embodiments, maintaining delivery may include slowing deliveryand then suddenly pushing hard (e.g., to invoke a jerk). Invoking a jerkmay be helpful in dislodging a cause of the occlusion (e.g., a jammedpiece of sand or other debris). In some embodiments, the ambulatorymedicament pump 4500 may delivery the therapy slowly or faster in anattempt to clear the occlusion. In some embodiments, the ambulatorymedicament pump 4500 may modify (e.g., reduce) the pressure within theambulatory medicament pump 4500 and/or related system parts. In responseto the determination that the fluid delivery parameter satisfies theinitial occlusion condition, the ambulatory medicament pump 4500 maypause delivery of therapy for a length of time. The length of time ofthe pause may be at least about 1 second, at least about 2 seconds, atleast about 3 seconds, at least about 5 seconds, at least about 10seconds, at least about 15 seconds, at least about 30 seconds, at leastabout 1 minute, or any length of time therebetween or fall within arange of any time having endpoints therein. In some embodiments, inresponse to the determination that the verification parameter satisfiesthe final occlusion condition, the ambulatory medicament pump 4500 mayincrease delivery of therapy to the subject after a passage of an amountof time. The amount of time may be about 10 seconds, about 20 seconds,about 30 seconds, about 45 seconds, about 1 minute, at least about 2minutes, about 3 minutes, about 5 minutes, or any amount of timetherebetween or fall within a range of any time having endpointstherein.

The ambulatory medicament pump 4500 may be configured to receive averification parameter associated with the possible occlusion. Theverification parameter can serve as a way for the ambulatory medicamentpump 4500 to determine whether the possible occlusion is actually aprobable occlusion. The verification parameter may be a separateindication that tends to confirm the existence of the occlusion. Forexample, the verification parameter may be received from a glucosedetector operatively coupled to the ambulatory medicament pump 4500. Theverification parameter can include a glucose level signal received fromthe glucose sensor configured to detect a glucose level of the subject.The glucose level signal can include one or more glucose parameters,such as a glucose level of the subject and/or an indication of a glucosetrend indicating at least a predicted change in the glucose level of thesubject. Additionally or alternatively, the verification parameter caninclude an amount of time before receiving another indication of thestatus of the possible occlusion. For example, the ambulatory medicamentpump 4500 may wait about 10 seconds, about 30 seconds, about 1 minute,about 2 minutes, about 5 minutes, about 10 minutes, about 15 minutes,about 30 minutes, about 45 minutes, about an hour, about 2 hours, about3 hours, or any amount of time therebetween or fall within a range ofany time having endpoints therein. In some embodiments, the verificationparameter can include a result from an action taken by the ambulatorymedicament pump 4500 in an attempt to further diagnose or otherwisecharacterize a possible occlusion (e.g., to support a determination thatit is a probable conclusion). Such an action may include supplying asudden increase in pressure by the pump motor 4508 or other action.

The ambulatory medicament pump 4500 may determine that the verificationparameter satisfies a final occlusion condition. If the verificationparameter supports the inference toward a probable occlusion, then thismay suggest that the final occlusion condition is satisfied. The finalocclusion condition indicates that a probable occlusion exists in themedicament delivery system. The final occlusion condition includes aglucose level indicating a threshold value of at least 150 mg/dL ofblood glucose concentration. Other values are possible. The initialocclusion condition and the final occlusion condition can be based ondifferent parameters. For example, the initial occlusion condition maybe based on a current drawn by the pump motor 4508 while the finalocclusion condition may be based on a glucose level signal of thesubject. Other combinations are possible.

In response to the determination that the verification parametersatisfies the final occlusion condition, the ambulatory medicament pump4500 can modify (e.g., reduce) delivery of therapy to the subject. Themodification of therapy may include providing less than the amount oftherapy delivered during the maintaining of therapy. For example, themodification of therapy can include reducing and/or essentially stoppingthe delivery of therapy. The stopping of delivery may be temporary. Insome examples, after stopping or reducing delivery for an amount of time(e.g., about 10 seconds, about 30 seconds, about 1 minute, etc.), theambulatory medicament pump 4500 may increase delivery of therapy to thesubject after a passage of an amount of time. Because of the pause intherapy, in some examples the ambulatory medicament pump 4500 willincrease delivery, at least temporarily, at a greater rate than the rateprior to the pause.

The ambulatory medicament pump 4500 can further generate a first useralert based at least in part on the determination that the fluiddelivery parameter satisfies the initial occlusion condition.Additionally or alternatively, the ambulatory medicament pump 4500 cangenerate a second user alert based at least in part on the determinationthat the verification parameter satisfies the final occlusion condition.The first and/or second user alert can be displayed via the userinterface. The first and/or second user alerts can be a sensory alert,such as a visual, tactile, aural, or other sensory alert. The sensoryalert may be an annoying and/or loud tone or voice, audible alarm, phonecall, and/or other kind of sensory alarm. The second user alert may beprovided to the subject receiving the therapy and/or another person orpersons. The second user alert may be configured to wake a sleepingsubject and/or caregiver.

In some embodiments, the ambulatory medicament pump 4500 may identify anintermediate occlusion condition and that the fluid delivery parametersatisfies the intermediate occlusion condition. In some cases, theintermediate occlusion condition may be satisfied after thedetermination of the initial occlusion condition. The ambulatorymedicament pump 4500 can determine that the fluid delivery parametersatisfies an intermediate occlusion condition, wherein the intermediateocclusion condition indicates that the possible occlusion persists. Inresponse to the determination that the fluid delivery parametersatisfies the intermediate occlusion condition, the ambulatorymedicament pump 4500 may modify an attribute of the delivery of therapy.The attribute of the delivery of therapy that is modified may include arate of delivery and/or a size of a bolus of therapy. The attribute mayinclude a delivery speed, a delivery interval, a delivery pressure, orimpulse, etc. The ambulatory medicament pump 4500 may modify theattribute of the delivery of therapy in order to invoke a jerk or tootherwise address a potential occlusion. In some examples, the attributemay relate to an action taken by the ambulatory medicament pump 4500 inan attempt to further diagnose or otherwise characterize a possibleocclusion (e.g., to support a determination that it is a probableconclusion).

Some embodiments of an occlusion detection system are described withreference to FIG. 45B. FIG. 45B is a schematic illustrating an exampleocclusion detection system 4514. The occlusion detection system 4514 caninclude a non-transitory memory 4516, an electronic hardware processor4518, and a user interface 4520. The user interface 4520 may include aninteractive graphical user interface, such as a smartphone or anothermobile device.

The processor 4518 may execute instructions stored on the memory 4516 toperform various functions. The occlusion detection system 4514 canreceive a fluid delivery parameter associated with a medicament deliverysystem. The medicament delivery system may include an ambulatorymedicament pump (e.g., the ambulatory medicament pump 4500) and/or othermedicament delivery system components, such as describe above. The fluiddelivery parameter may be the fluid delivery parameter described above.The occlusion detection system 4514 can determine that the fluiddelivery parameter satisfies an initial occlusion condition. The initialocclusion condition may indicate that a possible occlusion exists in themedicament delivery system. The occlusion detection system 4514 can sendan instruction to the medicament delivery system to maintain delivery oftherapy to the subject in response to the determination that the fluiddelivery parameter satisfies the initial occlusion condition.Additionally or alternatively, the occlusion detection system 4514 maygenerate a user alert based at least in part on the determination thatthe fluid delivery parameter satisfies the initial occlusion condition.The user alert may be generated via the user interface 4520.

The occlusion detection system 4514 can also receive a verificationparameter associated with the possible occlusion. The occlusiondetection system 4514 can then determine that the verification parametersatisfies a final occlusion condition. The final occlusion condition canindicate that a probable occlusion exists in the medicament deliverysystem. The occlusion detection system 4514 can send an instruction tothe medicament delivery system to modify (e.g., reduce) delivery oftherapy to the subject in response to the determination that theverification parameter satisfies the final occlusion condition. Theocclusion detection system 4514 can generate a user alert based at leastin part on the determination that the verification parameter satisfiesthe final occlusion condition.

FIG. 46A and FIG. 46B show methods for determining possible and/orprobable occlusions. FIG. 46A is a flow chart flow diagram illustratingan example method 4600 that may be used by an ambulatory medical deviceto maintain delivery of therapy to a subject after determining that apossible occlusion exists in a medicament delivery system. The method4600 may be performed by a system such as a medicament delivery systemincluding the ambulatory medicament pump 4500. At block 4602, the systemdetects a fluid delivery parameter associated with the medicamentdelivery system. At block 4604, the system determines that the fluiddelivery parameter satisfies an initial occlusion condition. The initialocclusion condition can indicate that a possible occlusion exists. Atblock 4606, the system maintains delivery of therapy to the subject inresponse to the determination that the fluid delivery parametersatisfies the initial occlusion condition. At block 4608, the systemreceives a verification parameter associated with the possibleocclusion. At block 4610, the system determines that the verificationparameter satisfies a final occlusion condition. The final occlusioncondition indicates that a probable occlusion exists in the medicamentdelivery system. At block 4612, the system may modify (e.g., reduce)delivery of therapy to the subject. The modification of therapy may bebased on the determination that the verification parameter satisfies thefinal occlusion condition.

FIG. 46B is a flow chart flow diagram illustrating an example method4614 that may be used by an occlusion detection system to maintaindelivery of therapy to a subject after determining that a possibleocclusion exists in a medicament delivery system. The method 4614 may beperformed by a system such as an occlusion detection system such as theocclusion detection system 4514. At block 4616, the system receives afluid delivery parameter associated with a medicament delivery system.At block 4618, the system determines that the fluid delivery parametersatisfies an initial occlusion condition. The initial occlusioncondition can indicate that a possible occlusion exists. At block 4620,the system sends an instruction to the medicament delivery system tomaintain delivery of therapy to the subject in response to thedetermination that the fluid delivery parameter satisfies the initialocclusion condition. At block 4622, the system receives a verificationparameter associated with the possible occlusion. At block 4624, thesystem determines that the verification parameter satisfies a finalocclusion condition. The final occlusion condition indicates that aprobable occlusion exists in the medicament delivery system. At block4626, the system may send an instruction to the medicament deliverysystem to modify (e.g., reduce) delivery of therapy to the subject. Themodification of therapy may be based on the determination that theverification parameter satisfies the final occlusion condition.

Example AMD with Alarm Muting

Alert fatigue can be an issue with medical devices due to excessivealerts which do not necessarily require user interaction. In many cases,an alarm condition may occur that does not require immediate userattention or may only be resolved by the manufacturer of the AMD.Persistent annunciation of such alarms may cause alert fatigue, whichcan be dangerous because it can lead users to ignore all alerts,including serious alerts or alerts that require action in the shortterm. Advantageously, the disclosed alarm system and methods mayimplement a Do Not Disturb mode which users may activate to mutenon-urgent alarms. The system and methods described herein can suppresslower urgency alarms during user selected periods. The user-selectedperiods can include times when a user is sleeping or in a meeting. Theseperiods of Do Not Disturb activation and deactivation can be controlledby the user. The system and methods can also provide for automatic oruser preselected/scheduled activation of the Do Not Disturb mode duringrecurring time periods or intervals, such as during the night when theuser is sleeping, with the Do Not Disturb mode being activated by thesystem during the recurring time period or interval. In some cases, arecurring time interval may include a time interval occurring every day(e.g., every day between 18:00 and 7:00, or between 20:00 and 6:00, orother time intervals.)

In some cases, lower urgency alarms may include at least alarms withseverity levels 0, 1, 2, and 3, as disclosed herein. Higher urgencyalarms (e.g., severity levels 3, 4, 5, etc.) may not be muted, bothduring usual operation of the AMD and when Do Not Disturb mode isactivated. In some cases, the user may define which severity levels areto be considered urgent in a Do Not Disturb session. It should be notedthat severity level alone may not be enough to determine whether analarm may be muted. In some cases, one severity level may encompass bothmute-eligible and mute-ineligible alarms. For example, in some cases,only some level 3 alarms may be muted. In such cases, when Do NotDisturb mode is activated, only the mute-eligible level 3 alarms may bemuted during Do Not Disturb mode, while the mute-ineligible alarms willbe annunciated as urgent alarms. In some cases, mute-eligible level 3alarms may include the level 2.5 alarms as described herein.

It should be noted that the alarm muting processes described herein maymute but not postpone detected alarm conditions. Though auditory andhaptic annunciations may be muted, details relating to each detectedalarm condition may be displayed on a list of pending alarm conditionsin real time and can be viewed by the user at any time. U.S. Pat. No.11,135,364 disclosing alarm status indication is incorporated byreference herein and made a part of this specification.

FIG. 47 shows a flow diagram illustrating an example procedure that maybe used by the alarm system of an AMD to mute non-urgent alarmconditions or in annunciating alarms. The process 4700 begins at block4702, when the device receives a request to activate alarm muting, or DoNot Disturb mode. As used herein, alarm muting may include activation ofthe Do Not Disturb mode and vice versa. For example, the request toactivate Do Not Disturb mode may include alarm muting instructions. Asdescribed herein, alarm muting or alarm muting instructions may includesilencing auditory and/or haptic annunciation of alarms whilemaintaining visual annunciation of the alarm condition (e.g. displayingthe alarm condition on a list of pending alarm conditions). In somecases, the do not disturb mode of the ambulatory medicament device maybe activated in response to determining that alarm annunciation shouldbe muted in accordance with the alarm muting instructions. In some suchcases, at least some alarm annunciation patterns may not be aurally orhaptically annunciated.

As described herein, a user may input various parameters as part of thealarm muting instructions when activating Do Not Disturb mode. In somecases, the user may define a start and end time between which alarmmuting is to remain activated. In some cases, the user may define alength of time over which alarm muting is to remain activated. In someother cases, the user may set alarm muting to recur at regular intervalsor time intervals, such as every night during a time frame the subjectis typically asleep. If the defined Do Not Disturb period does not beginimmediately, the system may annunciate alarms on an accelerated scheduleprior to activation of Do Not Disturb mode. For example, snoozed alarmsmay have alarm reminders that are annunciated at regular orpredetermined intervals until the alarm is resolved. In such cases, if areminder annunciation is scheduled to annunciate during the Do NotDisturb period (e.g., user scheduled Do Not Disturb period), the systemmay annunciate the reminder for the unresolved alarm prior to theactivation time of Do Not Disturb mode. In some cases, the user mayselect which alarms to mute when activating Do Not Disturb mode. In somecases, Do Not Disturb mode may be activated with a default selection ofalarms to be muted. In some cases, alarm muting instructions may includea recurring time interval indicating a time interval during which the donot disturb mode may be activated. In some examples, the recurring timeinterval may include a time interval (e.g., time between a start and anend time) occurring periodically (e.g., every day).

In response to the request, at block 4704, the system may activate alarmmuting in accordance with the specified alarm muting instructions. Atdecision block 4706, the system may check whether a request todeactivate Do Not Disturb mode has been received. A request todeactivate Do Not Disturb mode may be created manually by the user ormay be created automatically by the system. For example, if the definedperiod lapses for a Do Not Disturb session, the system may automaticallyrequest to deactivate Do Not Disturb mode. In some cases, the user maymanually terminate a Do Not Disturb session prior to the scheduleddeactivation time, as described herein in relation to FIG. 51. In suchcases, the system may receive a deactivation request when the usercancels the current Do Not Disturb session. If a request to deactivateDo Not Disturb mode has been received, the process 4700 may proceed toblock 4718. If a request to deactivate Do Not Disturb mode has not beenreceived, Do Not Disturb mode remains active and the process 4700 mayproceed to block 4708.

At block 4708, the system may detect an alarm condition. At decisionblock 4710, the system may determine whether the detected alarmcondition is an urgent alarm condition requiring urgent user attentionin the short term. In some cases, determining whether the alarmcondition is urgent may include comparing the severity level of thealarm condition against a threshold severity level. If the severitylevel of the alarm condition exceeds the defined threshold severitylevel, the alarm condition may be considered an urgent alarm requiringurgent user attention. In some cases, the threshold severity level maybe predetermined. In other cases, the threshold severity level may bedefined by the user as part of the alarm muting instructions. Furtherdetails relating to determining alarm urgency is described herein inrelation to blocks 4810 and 4812 of FIG. 48.

If the alarm condition is determined to be urgent, the process 4700continues to blocks 4712 and 4714, and the alarm condition may bedisplayed on a list of pending alarm conditions 5200 (FIG. 52) andannunciated in real time. After block 4714, the system may loop back orreturn to decision block 4706.

The system may maintain an indication of the alarm condition on the listof pending alarm conditions 5200 until the alarm condition is resolved.In some cases, the list of pending alarm conditions may be an alarmmanager list, and the user may interact with each listed alarm conditionto view alarm details, acknowledge the alarm, snooze the alarm, orotherwise resolve the alarm. If the alarm condition is determined not tobe urgent, the process 4700 proceeds to block 4716, where the alarmcondition is added to the alarm manager list, or list of pending alarmconditions, and the auditory and haptic annunciation associated with thealarm condition is muted. After block 4716, the system may loop back orreturn to decision block 4706.

While Do Not Disturb mode is activated, all alarms may continue to beraised, but auditory and haptic annunciation of some alarms may bemuted. Raised alarms may be added to the alarm manager list at the timeof detection and displayed on a user interface until the condition thatcaused the alarm is resolved. Thus, although an alarm condition may nothave an auditory or haptic alert, the user may still view the alarmcondition information and resolve the alarm condition. Resolving thealarm condition may include, but is not limited to, the user takingaction to correct the condition that caused the alarm, the useracknowledging the alarm, the user snoozing the alarm, or the device nolonger detecting the alarm condition (e.g., low blood glucose conditionis no longer present).

At block 4718, Do Not Disturb mode may be deactivated. As describedherein, Do Not Disturb mode may terminate automatically (e.g. thedefined time period in the alarm muting instructions has lapsed) or maybe manually deactivated. The user may override Do Not Disturb mode bymanually cancelling Do Not Disturb mode at any point while alarm mutingis activated. In some cases, the user may override a current Do NotDisturb session by inputting new alarm muting instructions. At block4720, the system may annunciate the most severe alarm condition from thelist of pending alarm conditions that has not yet been annunciated. Themost severe alarm condition may be associated with the highest severitylevel of the non-urgent alarms on the list of pending alarm conditions.The other alarm conditions on the list may remain muted but may continueto be displayed on the list until the alarm conditions are resolved.Previously annunciated alarms (e.g. urgent alarm conditions) may not beannunciated again in response to deactivation of Do Not Disturb mode.

In an example application of the process described in FIG. 47, thesystem may detect a first alarm condition, a second alarm condition, anda third alarm condition while in Do Not Disturb mode. The system mayfirst detect the first alarm condition at block 4708. At decision block4710, the system may determine that the first alarm condition is anurgent alarm condition. As such, the first alarm condition may be bothadded to the list of pending alarm conditions and annunciated in realtime, according to blocks 4712 and 4714. The system may then return orloop back to decision block 4706. Do Not Disturb mode may remain activeif the system does not receive a request to deactivate alarm muting.Without deactivating Do Not Disturb mode, then, the system may detectthe second alarm condition. At decision block 4710, the system maydetermine that the second alarm condition is not an urgent alarmcondition. Thus, the second alarm condition may be added to the list ofpending alarm conditions without auditory or haptic annunciation,according to block 4716. Returning again to decision block 4706, Do NotDisturb mode may remain active if the system does not receive a requestto deactivate alarm muting. Continuing to block 4708 withoutdeactivating Do Not Disturb mode, the system may detect the third alarmcondition. At decision block 4710, the system may determine that thethird alarm condition is also a non-urgent alarm condition. The thirdalarm condition may have a severity level lower than the second alarmcondition. At block 4716, the third alarm condition may be added to thelist of pending alarm conditions without auditory or hapticannunciation. Returning or looping back to block 4706, the system maythen receive a request to deactivate Do Not Disturb mode. The system maythen deactivate Do Not Disturb mode, at block 4718. In response to thedeactivation of Do Not Disturb mode, the system may annunciate the mutedalarm with the highest severity level, at block 4720. In this example,the system would annunciate the second alarm condition, since the firstalarm condition was already annunciated as an urgent alarm and the thirdalarm condition has a lower severity level.

In some cases, the system may deactivate the Do Not Disturb mode upon orin connection with annunciating the above first alarm condition, asdiscussed further below.

FIG. 48 is a flow diagram illustrating another example procedure inannunciating alarms or activating a Do Not Disturb mode in an AMD. Theprocess 4800 begins at block 4802, when the system receives a request toactivate Do Not Disturb mode. In response to the request, the system mayactivate Do Not Disturb mode at block 4804. At decision block 4806, thesystem may determine whether a request to deactivate Do Not Disturb modehas been received. The process at blocks 4802, 4804, and 4806 mayproceed according to the disclosure related to blocks 4702, 4704, and4706 of FIG. 47. If a request to deactivate Do Not Disturb mode has beenreceived, the process 4800 may proceed to block 4826. If a request todeactivate Do Not Disturb mode has not been received, Do Not Disturbmode remains active and the process 4800 may proceed to block 4808.

At block 4810, the system may determine a severity level of the alarmcondition. The severity level may be based on the underlying fault ofthe alarm condition. For example, a low battery warning may be assigneda low severity level (e.g. level 1), while an extremely low bloodglucose measurement may be assigned a high severity level (e.g. level5). At decision block 4812, the system may determine whether theseverity level of the first alarm condition exceeds a threshold severitylevel. The threshold severity level may be a predefined severity level,which if exceeded, may cause the system to determine that the alarmcondition is an urgent alarm condition requiring urgent user attentionin the short term. In some cases, the threshold severity level may bedefined by the user as part of the alarm muting instructions. Forexample, the user may want to be immediately alerted of any alarms thatare level 2 or higher. If the severity level of the alarm conditionexceeds the defined threshold severity level, then the alarm conditionis considered urgent and the process 4800 proceeds to block 4814. If theseverity level of the alarm condition does not exceed the definedthreshold severity level, the alarm condition is not considered urgentand the process 4800 proceeds to decision block 4820.

In block 4814, the system may automatically deactivate Do Not Disturbmode in response to detecting an urgent alarm condition. As describedherein, in some cases, the list of pending alarm conditions may bearranged in order of severity. In some cases, the alarm condition withthe highest severity level may be listed at the top of the list ofpending alarm conditions and the rest of the alarm conditions would belisted in descending order of severity level. In blocks 4816 and 4818,the alarm condition may be displayed at the top of the list of pendingalarm conditions 5200 as the alarm condition with the highest severitylevel and annunciated in real time. In some cases, the system may onlyannunciate the urgent alarm condition upon deactivation of Do NotDisturb mode. In some other cases, the system may also annunciate thesecond alarm on the list of pending alarm conditions (e.g. the mutedalarm condition with the highest severity level).

At decision block 4820, the system may determine whether the severitylevel of the detected alarm condition exceeds the severity level of themost severe alarm condition currently on the list of pending alarmconditions. If the severity level of the detected alarm conditionexceeds the highest severity level on the list of pending alarmconditions, the process 4800 proceeds to block 4822, where the alarmcondition may be listed at the top of the list of pending alarmconditions. After block 4822, the system may loop back or return todecision block 4806.

If the severity level of the alarm condition does not exceed the highestseverity level on the list of pending alarm conditions at the time, theprocess 4800 may proceed to block 4824, where the alarm condition may beadded to the list of pending alarm conditions in order of severitylevel. If the severity level of the detected alarm condition is equal tothe severity level of one or more other alarm conditions present on thelist, the detected alarm condition may be added to the list of pendingalarm conditions in chronological order within its severity level group.After block 4824, the system may loop back or return to decision block4806.

At block 4826, Do Not Disturb mode may be deactivated. As describedherein, Do Not Disturb mode may terminate naturally (e.g. the definedtime period in the alarm muting instructions has lapsed) or may bemanually deactivated. At block 4828, the system may annunciate the firstalarm condition from the list of pending alarm conditions (e.g. the mostsevere alarm condition). The other alarm conditions on the list mayremain muted but may continue to be displayed on the list until thealarm conditions are resolved.

FIG. 49 is a flow diagram illustrating an example procedure that may beused by the system to escalate a non-urgent alarm when Do Not Disturbmode is activated. The process 4900 begins at block 4902, where thesystem may activate Do Not Disturb mode. Do Not Disturb mode may beactivated in response to alarm muting instructions. In some cases, theuser may manually activate Do Not Disturb mode by inputting alarm mutinginstructions for immediate activation. In some cases, the user may inputalarm muting instructions to schedule a Do Not Disturb session to beginat a later time. In such cases, the system may automatically activate DoNot Disturb mode at the scheduled recurring time. In some cases, theuser may input alarm muting instructions to schedule recurring sessionsand the system may automatically activate Do Not Disturb mode for eachrecurring session.

At block 4904, the system may detect an alarm condition. At block 4906,the system may determine that the alarm condition is not urgent (e.g.does not require urgent user attention in the short term). In responseto a determination that the alarm condition is not urgent, the systemmay display the alarm condition on a list of pending alarm conditions,at block 4908.

At decision block 4910, the system may determine whether the timeelapsed from the detection of the alarm condition has exceeded athreshold amount of time. In some cases, the threshold amount of timemay be predetermined by the system. In some other cases, the thresholdamount of time may be defined by the user as part of the alarm mutinginstructions or through AMD settings. If the time elapsed since thedetection of the alarm condition has not exceeded the threshold amountof time, the process 4900 may return to block 4908 and the system maymaintain the alarm condition on the list of pending alarm conditions. Insome cases, maintaining the alarm condition on the list of pending alarmconditions may include maintaining the order in which the alarmcondition is displayed on the list. In some cases, maintaining the alarmcondition on the list of pending alarm conditions may includemaintaining the alarm condition details but adjusting the order of thealarm condition as later alarms are added to the list.

If the time elapsed since the detection of the alarm condition exceedsthe threshold amount of time, the process 4900 may proceed to block 4912and the alarm condition may be escalated. Escalating an alarm conditionmay include increasing the severity level of the alarm condition (e.g.increasing the severity level of the alarm condition from level 2 tolevel 3). It should be noted that the alarm condition may be escalatedby more than one severity level at a time (e.g. increasing the severitylevel of the alarm condition from level 1 to level 4 or starting fromany level (e.g., level 0) to be escalated to any other level (e.g.,level 5)).

At decision block 4914, the system may determine whether the alarmcondition at the new severity level is urgent. If the escalated alarmcondition is not urgent, the process 4900 may loop or return to block4908 and maintain the alarm condition display as disclosed herein. Ifthe escalated alarm condition is urgent, the process 4900 may proceed toblock 4916 and the alarm condition may be annunciated. For example, if alevel 2 alarm is considered non-urgent, it may be muted when the alarmcondition is first detected. However, if the alarm condition has notbeen resolved after a period of time, the system may escalate the alarmcondition from level 2 to level 3. If level 3 alarms are consideredurgent alarms requiring urgent user attention, then the alarm conditionmay be annunciated upon escalation. If level 3 alarms are alsoconsidered not urgent, then the alarm condition may remain muted.

FIG. 50 is an illustration of a plurality of screens 5000 that may bedisplayed on a touch screen display of an AMD for activating alarmmuting (Do Not Disturb Mode) on the AMD. As illustrated, a home screen5004 may include a menu icon 5002, an alarm status icon 5006, and a pumpoperation field 5020. The pump operation field 5020 may be automaticallyupdated at regular intervals to show high level subject information. Thealarm status icon 5006, in this exemplary embodiment, may be shaped asan alarm bell. The alarm status icon 5006 may be updated to provide highlevel information about alarm conditions of the AMD. In some cases, thealarm status icon 5006 may be an alarm bell with a counter in the middleindicating the number of annunciated alarms. In some cases, if there areno detected alarm conditions, the alarm status icon 5006 may display “0”or may not display any number or text. In some other cases, the alarmstatus icon 5006 may be updated with “zzz” or other visual cues toindicate that alarm muting, or Do Not Disturb (DND) mode, is activated.In some other cases, the alarm status icon 5006 may be in a shape of acrescent moon to indicate that alarm muting is activated. In yet othercases, the alarm status icon 5006 may not be a displayed icon. In suchcases, alarm status may be indicated by other forms of notification,such as, but not limited to, auditory, haptic, or visual cues (e.g. alight on the device that flashes when alarm conditions are detected).Selecting the alarm status icon 5006 may provide the user with access tothe list of pending alarm conditions 5200 (see FIG. 52). The menu icon5002, when selected, may display a menu screen 5008 through which theuser may control operation of the AMD. The menu screen 5008 may includean alarm muting button 5010. In some cases, the alarm muting button 5010may be shaped as an alarm bell with “zzz” to represent that the alarmalerts are silenced or snoozed.

Selecting the alarm muting button 5010 may display a Do Not Disturb(DND) setup screen 5012. The DND setup screen 5012 may display an alarmmuting control interface through which the user may input alarm mutinginstructions (e.g. defining a time frame for the Do Not Disturbsession). The alarm muting control interface may be controlled viatouchscreen controller. In some cases, the alarm muting controlinterface may be a dropdown or scroll-through menu from which the usermay select a length of time for which to activate alarm muting, asillustrated in FIG. 50. In some cases, the alarm muting controlinterface may be a time wheel, and the user may rotate the wheel toincrease or decrease the length of time for which to activate alarmmuting. In some cases, the alarm muting control interface may includeone or more text boxes in which the user may enter the amount of timefor which to activate alarm muting. In some cases, the alarm mutingcontrol interface may list time periods at regular increments, such as15-minutes increments, 30-minutes increments, 1-hour increments, 2-hourincrements, or the like. In some other cases, the alarm muting controlinterface may allow users to input a start time and an end time for theDo Not Disturb session, rather than inputting a length of time. Thestart time can be in the future to allow the user to plan or schedule aDo Not Disturb session. In yet other cases, the alarm muting controlinterface may have additional features to define recurring Do NotDisturb sessions. Once the user has input the alarm muting instructions,the user may select the Start button 5014. If Do Not Disturb mode is setto begin immediately, selection of the Start button 5014 will cause thesystem to display a confirmation page 5016 to inform the user that DoNot Disturb mode was activated. If Do Not Disturb mode is set to beginafter a period of time, the confirmation page 5016 may display Do NotDisturb confirmation information, including, but not limited to,recurrence information, defined start time, defined end time, and totalalarm muting time. For subject privacy, after a period of inactivity,the system may automatically lock the AMD and display a lock screen5018.

For subject safety, the system may include limitations on thepermissible length of time over which alarms may be muted. In somecases, the system may include limitations on the number of consecutivehours or the total number of hours alarm muting is activated within aday, within a week, or other timeframe. For example, the user may beable to activate Do Not Disturb mode up to a typical sleeping time butsubstantially less than a day. In some cases, the system may allowlonger periods of Do Not Disturb based on safe access level.Accordingly, the system may monitor the number of hours that Do NotDisturb has been active. Some alarms may include one set of limitationswhile other alarms may have a different set of limitations, includingdepending on the number of hours that Do Not Disturb has been active. Insome cases, some types of alarms (e.g., audio annunciation) may besilenced, while other alarms (e.g., haptic annunciation) may not besilenced. In some cases, the user may define which types of alarms areto be silenced.

As disclosed herein, Do Not Disturb mode may mute but not postponedetected alarm conditions. Though auditory and haptic annunciations maybe muted, the list of pending alarm conditions 5200 may be updated inreal time and can be viewed by the user at any time.

FIG. 51 is an illustration of a plurality of screens 5100 that may bedisplayed on a touch screen display of an AMD for deactivating alarmmuting, or Do Not Disturb mode, on the AMD. As described herein, thehome screen 5004 may include a menu icon 5002, an alarm status icon5006, and a pump operation field 5020. As illustrated, the alarm statusicon 5006 may be the shape of an alarm bell with “zzz” or other text toindicate that alarm muting is activated. As described herein, the menuicon 5002, when selected, may display a menu screen 5008 through whichthe user may control the AMD. The menu screen 5008 may include an alarmmuting button 5010. Selecting the alarm muting button 5010 may displaythe alarm muting control interface. In some cases, while alarm muting isactivated, the alarm muting control interface may be updated to show aDo Not Disturb setting screen 5104. In some cases, the setting screen5104 may show the time that the active Do Not Disturb session willexpire. If the user changes the display time of the device, theremaining duration of the Do Not Disturb period may be maintained suchthat the end time is updated with the new device display time.Alternatively, or in addition, the setting screen 5104 may show how muchlonger the Do Not Disturb mode is set to last. As described herein, theuser may override Do Not Disturb mode by manually cancelling Do NotDisturb mode at any point while alarm muting is activated. The settingscreen 5104 may include a Cancel button 5106. Selecting the Cancelbutton 5106 may cause the system to deactivate alarm muting and displaya cancellation confirmation page 5102. For subject privacy, after aperiod of inactivity, the system may automatically lock the AMD anddisplay the lock screen 5018.

In some cases, the Do Not Disturb setting screen 5104 may includeadditional options to change the current alarm muting settings. The usermay override the existing alarm muting settings by inputting new alarmmuting instructions. Submitting new alarm muting instructions mayterminate the existing session. The newly defined alarm mutinginstructions may override the existing Do Not Disturb parameters andbegin a Do Not Disturb mode session in accordance with the newly definedalarm muting instructions, such that the new Do Not Disturb session doesnot add onto the currently defined period. In some cases, the system maynot have a limit on the number of times which the user can initiate DoNot Disturb. For subject privacy, after a period of inactivity, thesystem may automatically lock the AMD and display the lock screen 5018.

FIG. 52 shows an example list of pending alarm conditions 5200 when DoNot Disturb mode is not activated. The list of pending alarm conditions5200 may include an alarm notification icon 5202. As illustrated, thealarm notification icon 5202 may be in the shape of an alarm bell. Insome cases, the alarm notification icon 5202 may be any shape thatmatches the alarm status icon 5006 displayed on the home screen 5004. Insome cases, the alarm notification icon 5202 may be displayed when oneor more alarm conditions have been detected without otherwise beingdisplayed when no alarm conditions have been detected. The list ofpending alarm conditions 5200 may display information regarding thealarm conditions, including, but not limited to alarm conditiondescription, cause of alarm condition, and date and time of alarmcondition. Each alarm condition may have an associated alarm statusindicator 5204, 5206. The alarm status indicator 5204, 5206 may beupdated to reflect various annunciation patterns. For example, asillustrated, an exclamation mark in a triangle may represent an urgentannunciation pattern. As illustrated, an exclamation mark in a circlemay represent a non-urgent annunciation pattern. In some cases, lowlevel alarm conditions may be represented by a letter “i” to indicate anotification-only or informational alarm condition. In some cases,urgent alarm conditions may be represented by multiple exclamation marksin a triangle or circle. Each alarm condition in the list of pendingalarm conditions 5200 may be selected to view further details about thealarm and to resolve the alarm. In some cases, an alarm statusindicators, may indicate whether an alarm condition was annunciated ormuted.

In some examples, urgent alarms may not be muted or snoozed, even whenDo Not Disturb mode is activated. In such cases, the alarm statusindicator 5204 for urgent alarms may not change as Do Not Disturb modeis activated and deactivated. In some examples, non-urgent alarms may bemuted or snoozed, either manually by the user or automatically asdefined by alarm muting instructions during a Do Not Disturb session. Insuch cases, the alarm status indicator 5206 for non-urgent alarms may beupdated to represent that the alarm condition has been muted or snoozed(FIG. 53A and FIG. 54A).

In some examples, the user may view an alarm using a user interfaceprovided on a touchscreen display, both when the display is locked andwhen the display is unlocked. FIG. 53A and FIG. 53B are illustrations ofsuch a user interface for accessing the alarm notifications screen whenthe display is locked. As illustrated, the home screen 5004 may includea lock status icon 5302, an alarm status icon 5006, and a pump operationfield 5020. The lock status icon 5302, as illustrated, may be in theshape of a padlock when the AMD is locked. In some cases, the lockstatus icon 5302 may be updated when the AMD is unlocked. For example,the lock status icon 5302 may be changed to the shape of an open padlockor replaced with the menu icon 5002 when the device is unlocked. Ifthere are existing alarm conditions, the alarm notification icon 5202may also be displayed on the interface.

FIG. 53A illustrates the user interface when there are detected alarmconditions. The alarm status icon 5006 may display the number ofdetected alarm conditions. The user may view the list of pending alarmconditions 5200 without unlocking the interface. Thus, for example, ifthe user selects the alarm status icon 5006 while there are existingalarms in the system, the list of pending alarm conditions 5200 mayappear. However, the user may not be able to select the alarms (e.g., tosee more information or interact with the alarms) because the device islocked. In such cases, the list of pending alarm conditions 5200 mayinclude the lock status icon 5302. If alarm muting is activated, mutedalarms may be associated with an alarm status indicator 5206, which maybe updated to represent that the alarm was muted or snoozed (“zz” asillustrated). As described herein, urgent alarms may not be muted whileDo Not Disturb mode is active, and thus the associated alarm statusindicator 5204 for urgent alarms may remain unchanged. If the alarmmuting is deactivated while pending alarms are still on the list ofpending alarm conditions 5200, the alarm status indicator 5206 fornon-urgent alarms may be updated to the usual alarm status indicatorassociated with the alarm condition, even if the alarm alert is notannunciated. For example, as illustrated, the “sensor expiring soon”alarm may not be annunciated even when Do Not Disturb mode isdeactivated, if the “battery alarm 24” alarm is a higher-severitynon-urgent alarm. Nonetheless, the alarm status indicator 5206 may beupdated to an exclamation point or information symbol as discussedherein, for example, with reference to FIG. 51.

FIG. 53B shows the user interface when there are no detected alarmconditions. The alarm status icon 5006 may display “0” or may notdisplay any number when there are no pending alarm conditions. In suchcases, selecting the alarm status icon 5006 may cause the system todisplay the display interface 5304 illustrated. The display interface5304 illustrated may inform the user that there are no alarm conditions.In such cases, because there are no alarm conditions, the alarmnotification icon 5202 may not be displayed. In some cases, the displayinterface 5304 illustrated may further include information as to whetherDo Not Disturb is activated.

In some examples, if the user unlocks the device, the home screen 5004illustrated in FIG. 54A and FIG. 54B may be displayed. FIG. 54A and FIG.54B are illustrations of a user interface for accessing the alarmnotifications screen when the display is unlocked. As illustrated, thehome screen 5004 may include a menu icon 5002, an alarm status icon5006, and a pump operation field 5020. Selecting the menu icon 5002 mayallow the user to update AMD settings.

FIG. 54A illustrates the user interface when there are detected alarmconditions. The alarm status icon 5006 may display the number ofdetected alarm conditions. Selecting the alarm status icon 5006 maycause the system to display the list of pending alarm conditions 5200.The user may then access alarm control functions by selecting an alarmcondition of interest. If alarm muting is activated, muted alarms may beassociated with an alarm status indicator 5206 for non-urgent alarms,which may be updated to represent that the alarm was muted or snoozed(“zz” as illustrated). As described herein, urgent alarms may not bemuted while Do Not Disturb mode is active, and thus the associated alarmstatus indicator 5204 for urgent alarms may remain unchanged. If thealarm muting is deactivated while pending alarms are still on the listof pending alarm conditions 5200, the alarm status indicator 5206 fornon-urgent alarms may be updated to the usual alarm status indicatorassociated with the alarm, even if the alarm alert is not annunciated.For example, as illustrated, the “sensor expiring soon” alarm may not beannunciated even when Do Not Disturb mode is deactivated, if the“battery alarm 24” alarm is a higher-severity non-urgent alarm.Nonetheless, the alarm status indicator 5206 may be updated to anexclamation point or information symbol as discussed herein, forexample, with reference to FIG. 51.

FIG. 54B illustrates the user interface when there are no detected alarmconditions. The alarm status icon 5006 may display “0” or may notdisplay any number when there are no pending alarm conditions. In suchcases, selecting the alarm status icon 5006 may cause the system todisplay the display interface 5402 illustrated. The display interface5402 illustrated may inform the user that there are no alarm conditions.In such cases, because there are no alarm conditions, the alarmnotification icon 5202 may not be displayed. In some cases, the displayinterface 5402 illustrated may further include information as to whetherDo Not Disturb is activated.

Example AMD with Power Saving Mode

The AMD may be operated in various modes to extend battery life. The AMDmay operate in a sleep mode, a low power mode, and/or a power savingmode. It shall be understood that the described modes are merelyillustrative and that the AMD may be configured to operate in othermodes not described herein, which may also extend battery life of thedevice.

The AMD may operate in a power saving mode to save power and minimizeuser disturbances as discussed herein. In some cases, the power savingmode may be activated by the user via one or more user inputs orinteraction as discussed herein. In some cases, the power saving modecan be entered or exited via a wake interface of the AMD as discussedherein. In some cases, the power saving mode can be entered or exitedvia a tap or other gestures on the AMD as discussed herein. In somecases, the power saving mode may be activated automatically by the AMDafter the AMD does not receive one or more user inputs or interactions(e.g., via the motion sensor or touchscreen) for a predetermined amountor period of time associated with a period of inactivity of a user notinteracting with the AMD or providing user input to the AMD.

In some cases, the AMD may have an always on screen (which can be a typeof user interface screen) that displays in the power saving mode certaindesired or predetermined status information, including critical statusinformation, that may be relatively more important for quick reviewduring glucose control therapy without having to unlock or wake the AMD.The AMD can display the always on screen in the power saving mode. Thecritical status information may be part of the status informationreceived by the AMD via the monitoring system interface as discussedherein. The status information can include device information pertainingto a condition of the ambulatory medicament device or subjectinformation pertaining to a condition of a subject. Advantageously, analways on screen displaying certain status information in the powersaving mode can allow a user to view the important or critical therapyand device information without having to turn on or wake the AMD. Thepower saving mode features discussed herein can reduce the number oftimes the user fully wakes the AMD.

FIG. 55 illustrates an example AMD 5500 with an always on user interfaceprovided on a display or touchscreen display 5502 while the AMD 5500 isin the power saving mode. The user interface may include certaincritical status information as part of the critical status informationinterface screen displayed on the touchscreen display 5502 while the AMD5500 is in the power saving mode. In some cases, while in the powersaving mode, the AMD 5500 may turn off a backlight used to illuminatethe touchscreen display 5502. In some cases, while in the power savingmode, the AMD 5500 may cause the touchscreen controller to not receiveor not respond to user input signals. For example, the AMD 5500 may notrespond to any user inputs on the touchscreen display 5502 via touchingor otherwise motioning on the touchscreen display 5502. The touchscreendisplay 5502 can have a filter configured to have a predeterminedviewing angle range relative to the touchscreen display such thatinformation cannot be seen on the touchscreen when viewed from an angleoutside of a predetermined viewing angle range relative to the plane ofthe display. The filter can be part of the privacy features of the AMD5500 (e.g., privacy mode as discussed herein.)

In some cases, the critical status information interface screen maydisplay a glucose level indicator 5504 as a critical status indicator.For example, as illustrated in FIG. 55, the glucose level of the subjectas discussed herein may be 115 mg/dL. The glucose level indicator 5504can be considered to be a subject status indicator. The AMD 5500 candetermine whether a glucose level of the subject is within apredetermined glucose range and generate a display of a glucoseinterface screen (which may be a type or be part of user interfacescreen). The AMD can display on the touchscreen display 5502 the glucoselevel indicator via a glucose interface screen to prioritize displayingthe status information corresponding to the glucose level not beingwithin the predetermined glucose range.

In some cases, the critical status information interface screen maydisplay a glucose trend indicator 5506 as a critical status indicator.For example, as illustrated in FIG. 55, the arrow may be flat toindicate that the glucose level is stable. In some instances, an arrowpointing up may indicate that the glucose level is rising. In someinstances, an arrow pointing down may indicate that the glucose level isfalling. The glucose trend indicator 5506 can be considered to be asubject status indicator.

In some cases, the critical status information interface screen maydisplay a therapy status indicator 5508 as a critical status indicator.For example, as illustrated in FIG. 55, the therapy status indicator5508 may be a circle that is animated (e.g., rotating) to indicate thatthe AMD 5500 is operating and providing glucose control therapy. Thetherapy status indicator 5508 may indicate when the delivery ofmedicament is paused or suspended. Another therapy status indicator mayindicate when glucose level is low. The therapy status indicator 5508can be considered to be a medicament device status indicator.

In some cases, the critical status information interface screen maydisplay an alarm status indicator 5510 as a critical status indicator.The alarm status indicator 5510 can be considered to be a medicamentdevice status indicator and can also be a type of alert statusindicator. As illustrated in FIG. 55, the alarm status indicator 5510may be a bell or bell icon. In some cases, the bell may include a numberdisplayed on the user interface within the bell indicating the number ofalarms presently on, for example, the list of pending alarms. The alarmstatus indicator 5510 may be an alarm bell with a counter in the middleindicating a count of alarm conditions. In some cases, when there are nodetected alarm conditions, the alarm status indicator 5510 may display“0” or may not display any number or text as illustrated in FIG. 55. Insome cases, the alarm status indicator 5510 may not include a counterand, instead, a separate alarm state icon may be displayed to indicatethe count of alarm conditions. In some cases, the alarm status indicator5510 can include the alarm state icon such as the counter beingdisplayed within the alarm status indicator 5510. In some cases, thealarm status indicator 5510 may be updated with “zzz” or other visualindicators or icons to indicate that alarm muting, or Do Not Disturbmode, is activated or that one or more alarms have been snoozed. In somecases, the alarm status indicator 5510 may be in a shape of a crescentmoon to indicate that alarm muting is activated.

In some cases, the critical status information interface screen maydisplay a remaining medicament level indicator 5512 as a critical statusindicator. For example, as illustrated in FIG. 55, the remainingmedicament level of, for example, insulin is indicated to presently befull (e.g., a solid outline of an insulin cartridge). The medicamentlevel indicator 5512 can be considered to be a medicament device statusindicator and can also be a type of alert status indicator.

In some cases, the critical status information interface screen maydisplay a battery level indicator 5514 as a critical status indicator.For example, as illustrated in FIG. 55, the battery level of the AMD5500 is indicated to presently be at full charge (e.g., a solid outlineof a battery). The battery level indicator 5514 can be considered to bea medicament device status indicator and can also be a type of alertstatus indicator. In some cases, the AMD 5500 can determine that a powerlevel of a battery of the AMD 5500 is below a predetermined power levelthreshold and generate a display of a battery status interface (whichmay be a type or be part of user interface screen). The AMD can displayon the touchscreen display 5502 a battery charging indicator on abattery status interface to prioritize displaying the status informationcorresponding to the power level being below the predetermined powerlevel threshold. The battery charging indicator may include, but is notlimited to, an image of a battery charger for the battery of the AMD5500.

With continued reference to FIG. 55, the user interface may includecertain other status information displayed on the touchscreen display5502 while the AMD is in the power saving mode. The status informationinterface screen may include the critical status information interfacescreen. The indicators 5504, 5506, 5508, 5510, 5512, and/or 5514 mayconsidered critical status information relative to other statusinformation such indicators 5516 and/or 5518. The critical statusinformation can include other information, icons, and/or indicatorsimportant or critical for user review while receiving glucose controltherapy, including while in the power saving mode.

In some cases, the status information interface screen may display alock status indicator 5516 as a status indicator. For example, asillustrated in FIG. 55, the lock status icon is displayed to be lockedor closed to indicate that the AMD 5500 is presently in a lockedstate/mode, including while in a power saving mode. While the AMD 5500may exit out of the locked mode via a wake mode indicator/interface 5520as discussed herein, other user interaction gestures such as tapping maycause the AMD 5500 to exit out of a locked state, where for example thelock status indicator 5516 is no longer displayed. The lock statusindicator 5516 can be considered to be a medicament device statusindicator. The lock status icon, as illustrated, may be in the shape ofa padlock when the AMD 5500 is locked. In some cases, the lock statusicon may be updated when the AMD 5500 is unlocked. For example, the lockstatus icon may be changed to the shape of an open padlock or replacedwith a menu icon when the AMD 5500 is unlocked. When there are existingalarm conditions, the alarm status indicator 5510 may be updated toindicate unresolved alarm conditions.

In some cases, the status information interface screen may display awake mode indicator or message 5518 as a status indicator. For example,as illustrated in FIG. 55, the wake mode indicator or message 5518indicates that user can tap the wake interface or button 5520 of the AMD5500 to wake the screen and/or cause the AMD 5500 to exit the powersaving mode. Waking the screen can include activating the touchscreencontroller such that the AMD 5500 is responsive to user input on thetouchscreen display. The wake mode button/interface 5520 can beconsidered to be a medicament device status indicator. The wake mode ofthe AMD 5500 can be considered a full functionality mode of the AMD 5500as described herein, for example, in reference to paragraphs[0094]-[0108] and [0332]-[0384] with all functions including thetouchscreen display fully active and functioning with minimal (e.g.,certain select) or no power saving features active. The wake mode of theAMD 5500 can include a fully functioning and interactive touchscreendisplay that refreshes at desired rate, such as 60 hertz, and updatesthat status icons and indicators at a desired standard rate. In somecases, the refresh rate of the touchscreen display can be greater than60 hertz, such as for example, 120 hertz or greater. The wake mode ofthe AMD 5500 can include a fully functioning motion sensor as discussedherein.

The user interface screen may include other wake mode indicator ormessage 5518, that indicate to the user what the wake modebutton/interface 5520 is and/or provides information for activating thewake mode. When in the wake mode, the user interacting with the wakemode button/interface 5520 (e.g., pressing the wake modeindicator/interface 5520) can cause the AMD to enter or activate thepower saving mode, including low power mode or sleep mode as discussedherein. The wake mode indicator or message 5518 may correspond to andindicate the location of the wake interface, may be a message tointeract with the wake interface to activate the wake mode, or both. TheAMD 5500 can generate and cause to display a power saving interfacescreen that includes the wake mode indicator. The power saving interfacescreen can be or be part of the user interface screens discussed herein.Once in the wake mode, the AMD 5500 may not display or stop displayingthe wake mode indicator or message 5518.

The user may interact with a wake mode button/interface 5520 to create awake request signal to unlock the AMD 5500. In response to the wakerequest signal, the AMD 5500 may deactivate or exit power saving mode.In some cases, when the wake request is received during a predefinedperiod of the day, the AMD can turn on or increase the brightness of thebacklight as part of entering the wake mode. For example, the AMD canturn on or increase brightness the backlight between 8 PM and 7 AM(e.g., when it is dark or nighttime) in response to receiving a wakerequest. During other times (e.g., 7 AM to 8 PM), the backlight can beturned on or brightness increased by for example holding the wake modebutton/interface 5520 for a first predetermined period of time (such as1-2 seconds). By holding the wake mode button/interface 5520 for a firstpredetermined period of time, the AMD 5500 can turn on or increasebrightness of the backlight to a dimmer state, such as 40-60%brightness, relative to maximum brightness. When the user holds the wakeinterface for a second predetermined period of time (such as 2-3seconds), the AMD 5500 can turn on or increase brightness of thebacklight to maximum brightness. The AMD 5500 can track or count alength of time that the user interacts with or presses the wake modeindicator/interface 5520. In the wake mode, the AMD may enter orreactivate the power saving mode when the user interacts with the wakemode button/interface 5520 as discussed herein.

The wake mode button/interface 5520 may include, but is not limited to,a physical button, a capacitive sensor, or an inductive sensor. In somecases, a wake button may be incorporated into the alphanumeric pad 3224.In some cases, the wake interface may be any one or more keys of thealphanumeric pad 3224. In some cases, the wake interface may be acapacitive button that detects a change in capacitance. The wakeinterface may have a computing component for interpreting and executinginstructions from the signal processing component. Thus, the wakeinterface can follow a program that is dictated by the signal processingcomponent.

In some cases, the AMD 5500 in the power saving mode can refresh,update, change, or animate the status information screens, including thecritical status information screens, less frequently or at a lessfrequent rate than updating the status interface screens in a wake mode.For example, the AMD 5500 can refresh, update, change, or animate thestatus information icons or indicators, including the critical statusinformation indicators or icons, less frequently or at a less frequentrate than updating the status information indicators or icons in a wakemode. In some cases, certain critical status indicators may be updatedat different rates. For example, some critical status indicators may beupdated at a wake mode refresh rate, while other critical statusindicator or other status indicators may be updated at a less frequentor power saving refresh rate. Certain status information may not beupdated in the power saving mode. For example, the lock status indicator5516 may not be updated until the AMD 5500 changes modes from the powersaving mode to the wake mode.

In some cases, the AMD 5500 in the power saving mode can lower a refreshrate of the touchscreen to a lower refresh level relative to a maximumrefresh rate of touchscreen. The lower refresh rate in the power savingmode can be for example 0.1, 0.5, 1, 1.5, 2, 2.5 3, 4, 5 or more hertz.The lower refresh rate in the power saving mode is less than the refreshrate of in the wake mode of, for example, 60 hertz. In some cases, theAMD 5500 in the power saving mode can lower brightness or dim of thetouchscreen display 5502 to a lower brightness level relative to a fullbrightness level of the display. For example, the brightness may be 5,10, 15, 20, 25, 30, 40, 50, or 60% brightness relative to the fullbrightness of the touchscreen display 5502.

In some cases, the AMD 5500 in the power saving mode can lowerbrightness or dim a backlight of the touchscreen display 5502 to a lowerillumination level relative to a maximum illumination level of thebacklight. For example, the brightness may be 5, 10, 15, 20, 25, 30, 40,50, or 60% brightness relative to the full brightness of the backlight.The backlight can illuminate the touchscreen display 5502 and have anadjustable brightness separate from the adjustable brightness of thetouchscreen display 5502. While in the power saving mode, the AMD 5500can display the critical status information interface screen whileusing, for example, 5-10% additional electric current relative toelectric current used with the display turned off (e.g., sleep mode asdiscussed herein) with the AMD 5500 operating (providing glucose controltherapy). For example, the AMD 5500 can draw an additional 100-200milliamps of additional current (5-10% more) without changes/updates tothe screen on top of the 2-4 milliamps that the AMD 5500 may draw whiledelivering glucose control therapy without the display being on.

The combination of the AMD 5500 displaying certain critical statusinformation, less frequent update of status indicators/icons, lowerrefresh rate of the display, lower brightness of the display, and/orlower brightness of the backlight (or turning of the backlight) can beconsidered to be a low power mode. For example, in low power mode, theAMD 5500 may update the display less frequently compared to when in thewake mode. For example, the AMD may update the display every 1 minute,every 2 minutes, every 5 minutes, or more. Between updates, the displaycan be a static screen that draws minimal current to stay on asdiscussed herein.

The low power mode can be a variant of the power saving mode that forexample allows display of certain critical status information asdiscussed herein. The low power mode can be a type of power saving mode.For example, the power saving mode can include displaying certaincritical status information with an always on screen as discussedherein. When the AMD 5500 functions to achieve additional power savingsvia lower frequency refresh or updates, lower brightness, etc., this canbe considered a low power mode that helps achieve the lowered 5-10%additional electric current draw relative to the display being off.

When the display (as well as the backlight) is turned off while the AMD5500 continues to provide glucose control therapy, this can beconsidered a sleep mode. The sleep mode can be a variant of the powersaving mode that for example allows for certain user interaction such astapping as discussed herein while the display and backlight are off. Thelow power mode can be a type of power saving mode. The sleep mode can beused during the day or at night while the subject sleeps. With thedisplay and backlight off, the AMD may achiever further power savingsrelative to the lower power mode.

In some cases, the AMD 5500 can have a privacy mode. The privacy modemay be activated by the user or the AMD 5500 can activate the privacymode automatically based on time of day or geolocation. The user mayactivate the privacy mode via one or more user interface via a menu oricon selection as discussed herein. The AMD 5500 can generate a privacymode interface screen and display on the privacy mode interface screenone or more status indicators corresponding to the status informationwithout displaying at least one of the critical status indicators thatmay contain relatively sensitive information. For example, the criticalstatus information interface screen or the privacy mode interface screenmay omit or not display the glucose level indicator, the therapy statusindicator, or both. In some cases, none of the critical statusindicators are displayed while privacy mode is active. For example, thecritical status information interface screen may only show a lock symbolor an indication that privacy mode is activated.

In some cases, privacy mode can include activating the sleep mode suchthat display is off while the AMD 5500 delivery glucose control therapy.In some other cases, the display may be turned off while privacy mode isactivated. Privacy mode may be activated independently or in conjunctionwith power saving mode. For example, the AMD 5500 may allow the user toconfigure the power saving mode to activate the privacy mode when thepower saving mode is activated as discussed herein. In some cases, theAMD 5500 may allow the user to configure to activate the privacy modeafter the power saving mode is activated. In some cases, the AMD 5500may allow the user to configure to activate the privacy mode without thepower saving mode being activated. The privacy mode can be configured tobe activated via a wake interface discussed herein.

FIG. 56 is a flow diagram 5600 illustrating an example procedure toactivate a power saving mode in an AMD. As discussed herein, the AMD canactivate the power saving mode upon receiving a request from the user5602 (e.g., via a wake interface or menu selection on the touchscreendisplay). In some cases, when the AMD does not receive a user request toactivate the power saving mode and the user is otherwise not interactingwith the AMD (e.g., selecting through menus, reviewing alarms, reviewinginformation on the AMD, etc.), the AMD can activate the power savingmode after a predetermined amount of time has passed 5604 associatedwith a period of inactivity of a user not interacting with the AMD orproviding user input to the AMD. Once the AMD has entered or begunentering into the power saving mode, the AMD can deactivate thetouchscreen controller 5606 such that the touchscreen controller doesnot receive or does not react to user input signals corresponding to theuser input on the touchscreen display. In some cases, when the backlightwas on for example, the AMD can lower or dim the brightness or thebacklight (e.g., lower or dim illumination level of the display relativeto a maximum illumination level) or turn off the backlight 5608 toachieve power savings in the power savings mode. In some cases, the AMDmay implement other power saving features as discussed herein, such asreduced refresh and update rates, etc. The AMD may receive statusinformation, including critical status information, 5610 as discussedherein. The AMD may then display the status information, includingcritical status information, 5612 as discussed herein. The AMD mayutilize the always on screen functionality, including variation thereof,as discussed herein.

In some cases, the AMD may exit out of the power saving mode when theuser wakes the device via a wake interface as discussed herein. In somecases, the AMD may exit out of the power saving mode via other userinteractions or gestures. For example, the AMD may exit out of the powersaving mode via a user interaction corresponding to a single or doubletap on the AMD that the AMD determines via a motion sensor. In somecases, the user may interact with the AMD and command the AMD via userinteraction with the AMD corresponding to taps or other gestures on theAMD while the AMD remains in the power saving mode. For example, theuser may snooze alarms or toggle the display to turn on or off withoutthe AMD exiting the power saving mode (e.g., without entering the wakemode).

Example AMD with Motion Sensor

As discussed herein, the AMD can have one or more user interactionsensors. The user interaction sensors can include motion sensors. Themotion sensor can include an accelerometer, gyroscope, and/or otherelectrical or mechanical motion sensors that convert motion oracceleration into electrical signals. The electrical signals can be sentto the one or more controllers of the AMD as user interaction signals.In some cases, the motion sensors can be part of the device sensors 3208as discussed herein. The motion sensor can detect, for example, a singletap or a double tap anywhere on the AMD, including on the touchscreendisplay. The motion sensor can detect and send user interaction signalsassociated with any number of taps, such as for example, a triple tap, aquadruple or more taps on the AMD. In some cases, other user interactiongestures detected by the motion sensor can be used with the AMD asdiscussed herein in combination with or in lieu of taps. For example,other user interaction gestures may include shaking the AMD, moving theAMD, tilting the AMD, picking up the AMD, and/or the like that mayactivate or initiate functionality of the AMD as discussed herein inreference to tapping.

FIG. 57 is a flow diagram 5700 illustrating an example procedure for tapinteraction in a power saving mode of an AMD. The tap interaction can bea single tap. In some cases, the tap interaction for flow diagram 5700as discussed below in reference to FIG. 57 can be a double tap. In somecases, the user interaction with AMD for flow diagram 5700 can beanother user interaction with the AMD as discussed herein.

A tap interaction, such as a single tap, can turn on or off the display.Turning on or off the display via taps, for example single taps, can becalled toggling the display or toggling on or off the display withoutdeactivating or exiting the power saving mode while toggling certainpower saving mode features, such as temporarily turning on the display.

With reference to FIG. 57, the AMD can enter or activate the powersaving mode 5702 as discussed herein. Upon entering or activating thepower saving mode, the AMD can deactivate the touchscreen controller5704 as discussed herein so that the AMD does not register or react touser input on the touchscreen display. In the power saving mode, the AMDcan display status information 5706, which can include critical statusinformation, on the display, for example with an always on screen. Themotion sensor of the AMD can remain active such that the AMD can receiveand respond to user interaction with the AMD.

The AMD can detect a tap 5708, such as a single tap, on the AMD asdiscussed herein via the motion sensor sensing user interaction with theAMD corresponding to the tap. The AMD can turn off the display 5710. Forexample, in turning off the display, the AMD may enter into the sleepmode as discussed herein while still continuing to provide glucosecontrol therapy.

The AMD can detect another tap 5712, such as another single tap, afterturning off the display. The AMD can turn on the display 5714 andcontinue displaying the status information 5706.

FIG. 58 is a flow diagram 5800 illustrating another example procedurefor tap interaction in a power saving mode of an AMD. The tapinteraction can be a double tap. In some cases, the tap interaction forflow diagram 5800 as discussed below in reference to FIG. 58 can be asingle tap. In some cases, the user interaction with AMD for flowdiagram 5800 can be another user interaction with the AMD as discussedherein.

A tap interaction, such as a double tap, can turn on or off thebacklight. Turning on or off the backlight via taps, for example doubletaps, can be called toggling the backlight or toggling on or off thebacklight without deactivating or exiting the power saving mode whiletoggling certain power saving mode features, such as turning on thedisplay.

With reference to FIG. 58, the AMD can enter or activate the powersaving mode 5802 as discussed herein. Upon entering or activating thepower saving mode, the AMD can deactivate the touchscreen controller5804 as discussed herein so that the AMD does not register or react touser input on the touchscreen display. In the power saving mode, the AMDcan display status information 5806, which can include critical statusinformation, on the display, for example with an always on screen. Themotion sensor of the AMD can remain active such that the AMD can receiveand respond to user interaction with the AMD.

The AMD can detect a tap 5808, such as a double tap, on the AMD asdiscussed herein via the motion sensor sensing user interaction with theAMD corresponding to the tap. The AMD can turn on or increase thebrightness of the backlight 5810 used to illuminate the display. The AMDcan turn on the backlight when the backlight was off, for example, inthe power saving mode. The AMD can increase brightness of the backlightwhen the backlight was on, but not at maximum illumination for example,in the power saving mode.

The AMD can detect another tap 5812, such as another double tap, afterturning on or increasing the brightness of the backlight of the display.At step 5816, the AMD can turn off the backlight when the backlight waspreviously off when the first double tap in step 5808 was received. Insome case, at step 5816, the AMD can keep the backlight on and decreasethe brightness when the backlight was on when the first double tap instep 5808 was received and the brightness was increased in step 5810.

In some cases, when the AMD does not detect another tap, such as anotherdouble tap, the AMD can turn off the backlight or decrease thebrightness of backlight 5816 after a predetermined amount of time haspassed 5814 associated with the backlight being on or at increasedbrightness for a certain time period when the AMD is in the power savingmode. The AMD can continue displaying the critical status information5806.

FIG. 59 is a flow diagram 5900 illustrating another example procedurefor tap interaction in a power saving mode of an AMD. The tapinteraction can be a single tap. In some cases, the tap interaction forflow diagram 5900 as discussed below in reference to FIG. 59 can be adouble tap. In some cases, the user interaction with AMD for flowdiagram 5900 can be another user interaction with the AMD as discussedherein.

With reference to FIG. 59, the AMD can enter or activate the powersaving mode 5902 as discussed herein. Upon entering or activating thepower saving mode, the AMD can deactivate the touchscreen controller5904 as discussed herein so that the AMD does not register or react touser input on the touchscreen display. The power saving mode of flowdiagram 5900 can include turning off the display as discussed herein forexample in reference to a sleep mode. Accordingly, the AMD can turn offthe display 5906 as part of entering or activating the power savingmode. The motion sensor of the AMD can remain active such that the AMDcan receive and respond to user interaction with the AMD.

The AMD can detect a tap 5908, such as a single tap, on the AMD asdiscussed herein via the motion sensor sensing user interaction with theAMD corresponding to the tap. The AMD can turn on the display 5910. Atstep 5912, the AMD can display status information, which can includecritical status information, on the display. In some cases, the AMD candisplay alarms that were previously snoozed (e.g., indication via alarmstatus icons) in response to the tap 5908 when turning on the display5910. In some cases, the AMD may activate the touchscreen controller aspart of turning on the display 5910 such that the user can interact withthe AMD via user input using the touchscreen display as discussedherein.

The motion sensor of the AMD can remain active such that the AMD canreceive and respond to user interaction with the AMD. The AMD can remainin the power saving mode after detecting the tap 5908. In some cases,the AMD may exit or deactivate the power saving mode and enter adifferent mode in response to the tap. For example, the AMD may enter awake mode in response to the tap 5908.

The AMD can detect another tap 5914, such as another single tap, afterturning on the display and displaying the status information. The AMDcan turn off the display 5906 after detecting the other tap 5914. Insome cases, the AMD can enter or activate the power saving mode inresponse to tap 5914. For example, the AMD can enter or activate thepower saving mode when the AMD entered the wake mode in response to tap5908.

In some cases, when the AMD does not detect another tap, such as anothersingle tap, the AMD can turn off the display after a predeterminedamount of time has passed 5916 associated with the display being on fora certain time period. In some cases, when the AMD does not detectanother tap, such as another single tap, the AMD can turn off thedisplay after a predetermined amount of time has passed 5916 associatedwith the display being on for a certain time period when the AMD is inthe power saving mode. In some cases, the AMD can reenter or reactivatethe power saving mode after a predetermined amount of time of notdetecting another tap where the AMD had exited the power saving mode,such as for example, in response to the detecting the tap 5908.

FIG. 60 is a flow diagram 6000 illustrating another example procedurefor tap interaction in a power saving mode of an AMD. The tapinteraction can be a double tap. In some cases, the tap interaction forflow diagram 5900 as discussed below in reference to FIG. 60 can be asingle tap. In some cases, the user interaction with AMD for flowdiagram 6000 can be another user interaction with the AMD as discussedherein.

The AMD can enter or activate the power saving mode 6002 as discussedherein. Upon entering or activating the power saving mode, the AMD candeactivate the touchscreen controller 6004 as discussed herein so thatthe AMD does not register or react to user input on the touchscreendisplay. The power saving mode of flow diagram 6000 can include turningoff the display as discussed herein for example in reference to a sleepmode. Accordingly, the AMD can turn off the display 6006 as part ofentering or activating the power saving mode. The motion sensor of theAMD can remain active such that the AMD can receive and respond to userinteraction with the AMD.

The AMD can detect a tap 6008, such as a double tap, on the AMD asdiscussed herein via the motion sensor sensing user interaction with theAMD corresponding to the tap. The AMD can turn on the display 6010. Insome cases, the AMD may activate the touchscreen controller as part ofturning on the display 6010 such that the user can interact with the AMDvia user input using the touchscreen display as discussed herein. TheAMD can turn on backlight 6012 used to illuminate the display. In somecases, the AMD may delay turning on the backlight after turning on thedisplay for a predetermined time period and/or until detecting anotheruser interaction with the AMD such as the AMD being moved, includingbeing picked up.

In some cases, the AMD can display status information, which can includecritical status information, on the display as discussed herein, forexample in reference to step 5912. The motion sensor of the AMD canremain active such that the AMD can receive and respond to userinteraction with the AMD. The AMD can remain in the power saving modeafter detecting the tap 6008. In some cases, the AMD may exit ordeactivate the power saving mode and enter a different mode in responseto the tap 6008. For example, the AMD may enter a wake mode in responseto the tap 6008.

The AMD can detect another tap 6014, such as another double tap, afterturning on the display and the backlight. The AMD can detect another tap6014, such as another double tap, and turn off the backlight or decreasethe brightness of backlight 6018. In some cases, the AMD can enter oractivate the power saving mode in response to tap 6014. For example, theAMD can enter or activate the power saving mode when the AMD entered thewake mode in response to tap 6008.

In some cases, when the AMD does not detect another tap, such as anotherdouble tap, the AMD can turn off the backlight or decrease thebrightness of backlight 6018 after a predetermined amount of time haspassed associated with the backlight being on. In some cases, when theAMD does not detect another tap, such as another double tap, the AMD canturn off the backlight or decrease the brightness of backlight 6018after a predetermined amount of time has passed associated with thebacklight being on when the AMD is in the power saving mode. In somecases, the AMD may decrease the brightness of the backlight after thepredetermined amount of time before turning off the display 6006 afteranother or second predetermined amount of time as discussed below.

The AMD can turn off the display 6006 after detecting the other tap6014. In some cases, when the AMD does not detect another tap, such asanother double tap, the AMD can turn off the display 6006 after apredetermined amount of time has passed 6016 associated with the displaybeing on for a certain time period. In some cases, when the AMD does notdetect another tap, such as another double tap, the AMD can turn off thedisplay 6006 after a predetermined amount of time has passed 6016associated with the display being on for a certain time period when theAMD is in the power saving mode. In some cases, the AMD can reenter orreactivate the power saving mode after a predetermined amount of time ofnot detecting another tap where the AMD had exited the power savingmode, such as for example, in response to the detecting the tap 6008.

In some cases, the AMD can first dim or decrease the brightness of thebacklight after a first predetermined amount of time has passed 6016without receiving another tap. After a second predetermined amount oftime has passed (e.g., with a dimmed backlight), the AMD can turn offthe display 6006.

FIG. 61 is a flow diagram 6100 illustrating another example procedurefor tap interaction with an ambulatory medical device. The tapinteraction can be a double tap. In some cases, the tap interaction forflow diagram 6100 as discussed below in reference to FIG. 61 can be asingle tap. In some cases, the user interaction with AMD for flowdiagram 6100 can be another interaction with the AMD as discussedherein.

In some case, the AMD may operate based on the flow diagram 6100 in thepower saving mode with an always on screen as discussed herein. In somecases, the AMD may operate based on the flow diagram 6100 in the powersaving mode without an always on screen, such as in the sleep mode withthe display off as discussed herein. The AMD may turn on the display tonotify of an alarm condition and turn off the display after the alarm issnoozed or otherwise acknowledged without exiting the power saving mode.In some cases, the AMD may exit or deactivate the power saving mode whenthe alarm condition detected in flow diagram 6100 corresponds to anurgent or high severity alarm as discussed herein. In some cases, theAMD may operate based on the flow diagram 6100 in a wake mode to snoozean alarm via tapping gesture(s) as discussed herein.

With reference to FIG. 61, the AMD can detect an alarm condition 6102being present as discussed herein. For example, the AMD may receivestatus information via the monitoring system interface. The AMD maydetermine that the status information satisfies an alarm condition forthe ambulatory medicament device and/or for the subject. The AMD canthen display on the display one or more alarm status indicatorscorresponding to the alarm condition 6104 as discussed herein.

In some cases, the AMD can turn on the display when the display was offas discussed herein for the power saving mode or sleep mode. In somecases, the AMD may be operating with an always one screen as discussedherein. In some cases, the AMD can announce the alarm condition 6104using an auditory annunciation pattern or a haptic annunciation pattern,or both. The AMD can use the auditory and/or haptic annunciation patternin combination with displaying the one or more alarm status indicatorsor can use the auditory and/or haptic annunciation pattern when notdisplaying the one or more alarm status indicators (e.g., the display isoff). The various annunciation and display combinations can be set bythe user for the AMD and/or can be part of the modes of operation of theAMD discussed herein. For example, in the sleep mode, the AMD maydefault to auditory and/or haptic annunciation pattern without turningon the display when the display is off.

As discussed herein, the motion sensor of the AMD can remain active suchthat the AMD can receive and respond to user interaction with the AMD.The AMD can detect a tap 6106, such as a double tap, on the AMD asdiscussed herein via the motion sensor sensing user interaction with theAMD corresponding to the tap. The AMD can snooze the alarm or alarmcondition 6108. In some cases, snoozing the alarm can include the AMD nolonger displaying the one or more alarm status indicators on the displayafter being displayed in response the alarm condition. For example, theAMD can display the one or more alarm status indicators in response tothe alarm condition and stop displaying the one or more alarm statusindicators when the user snoozes the alarm. In some cases, when the AMDwas in the sleep mode with the display off, the AMD can turn on thedisplay to display the one or more alarm status indicators, and after apredetermined period of time, turn off the display again to reenter thesleep mode with the screen mode (without exiting the power saving mode).

In some cases, the AMD can determine that alarm condition requiresurgent user attention based on, for example, a severity level of thealarm as discussed. When the alarm condition requires urgent userattention, the AMD can prevent or not allow the alarm to be snoozed viafor example taps or other user interactions as discussed herein. In somecases, in response to determining that the alarm requires urgent userattention, the AMD can deactivate or exit the power saving mode into,for example, the wake mode. In some cases, in response to determiningthat the alarm requires urgent user attention, the AMD can deactivate orexit the sleep mode (e.g., operating with the display off) and continueoperating in the power saving mode with, for example, an always onscreen. In some cases, the AMD can allow low priority or not urgentalarms to be snoozed as discussed herein. In some cases, whether AMDallows the alarm to be snoozed or not, the AMD can deactivate or exitthe power saving mode into, for example, the wake mode when an alarmcondition is detected (e.g., inter wake mode regardless of whether thealarm is urgent or low priority)

In some cases, in response to snoozing the alarm, the AMD may update thealarm condition or alarm information with snoozed status 6110, such asupdating the one or more alarm status indicators to indicate that aparticular alarm has been snoozed. For example, the alarm statusindicators may include or be changed to alarm status icons that indicatean alarm condition has been snoozed.

In some cases, the AMD can move or add the snoozed alarm statusindicators to a list of pending alarm conditions. The list of pendingalarm conditions can include indications or the alarm status iconsassociated with the alarm status indicators that indicate the alarmcondition has been snoozed. Adding the snoozed alarm status indicatorsor alarm status icons to the list of pending alarm conditions can bepart of the step of no longer displaying the one or more alarm statusindicators on the display in response to the alarm being snoozed. Forexample, the AMD may not display the list of pending alarm conditions(which can include snoozed or as well as non-snoozed alarms) on analways one screen in a power saving mode of the AMD. The list of pendingalarm conditions may then be later access via user input/interactionwith AMD or for example, when entering the wake mode.

In some cases, the AMD can update, increment, and/or display an alarmstatus indicator (e.g., alarm status indicator 5510) with a counter thatshows the number of alarm on the list of pending alarm conditions and/orwhether one or more alarm conditions have been snoozed. After updatingthe alarm condition as snoozed, the AMD can display on the displayand/or annunciate (auditory and/or haptic annunciation pattern) a snoozeconfirmation 6112 that the alarm condition has been snoozed. In somecases, the snooze confirmation may be or include the step of updatingand/or changing the alarm status icons and/or incrementing a counter ofthe alarm status icon. After snooze confirmation 6112, the AMD can stopdisplaying the alarm status indicators on the user interface screen in,for example, the always on screen in the power saving mode of the AMD.In some cases, the AMD can stop displaying the alarm status indicatorson the user interface screen when a predetermined period of time haspassed after snoozing the alarm.

Additional embodiments relating to interacting with an ambulatorymedicament device that can be combined with one or more embodiments ofthe present disclosure are described in PCT Application No.PCT/US2020/054025, filed on Oct. 2, 2020 and titled “BLOOD GLUCOSECONTROL SYSTEM,” the disclosure of which is hereby incorporated byreference in its entirety herein for all purposes.

AMD Motion Detection

In some cases, an unexpected situation may occur that impacts theoperation of the ambulatory medicament device (AMD) such as an externalimpact or damage to the AMD. For an AMD that includes various mechanicalcomponents, there is a risk that external or internal damage to themechanical components (intentionally or unintentionally) may cause achange in therapy previously set by a user or any other user, so thatthe medicament may not be properly delivered to a subject. Further, theAMD may have settings inadvertently modified by a collision when the AMDis accidentally dropped. In various embodiments, a user may be thesubject who is receiving medicament or therapy, a clinician orhealthcare provider, a parent or guardian, or any other user who may bepermitted to modify settings of the ambulatory medicament device.

When there is a high acceleration impact, such as by a sudden drop ofthe AMD, a pump motor (e.g., motor 312) can be externally and/orinternally damaged to operate in delivery of the accurate therapy to thesubject. When there is an external damage to the AMD, medicamentdelivery error may occur which can lead to a dangerous situation for thesubject. For example, in a case in which the motor is suddenly damagedwhile delivery of the medicament is being performed, a change in thedelivery amount may unintentionally happen without any notice. In thissituation, the subject may not even be aware of such a change. Inaddition, the AMD may stop operating, manually or automatically when theAMD is dropped. In some cases, when the AMD is not programmed to storeor have any backup data (e.g., the number of turns of the motor used toprovide the specific therapy individualized for a specific subject), aninaccurate amount of delivered medicament may be recorded. The user maynot even be aware of any such circumstances.

In addition, current regulations require that the delivered amount ofmedicament match the amount prescribed. Thus, the delivery of medicamentto the subject may need to be immediately terminated when damage to theAMD is anticipated. The delivery of an inaccurate amount of medicamentcan be averted in contravention with the prescribed amount ofmedicament.

In some embodiments, therefore, an ambulatory medicament device (AMD)may be configured to detect the sudden motion and to prevent aninadvertent modification to a control parameter and/or to medicamentdelivery. The sudden motion may include an event of sudden dropping ofthe AMD by a user or any external impact to the AMD.

Accordingly, in some embodiments, the AMD may include a sensor (e.g.,device sensors 3208 in FIG. 32) which may be one or more motion sensors,an accelerometer, or a geolocation system to detect an external impacton the AMD or a motion of the AMD. The aforementioned sensor or sensorsmay be used to determine or detect a velocity of the AMD and/or thesubject. In various embodiments, one or more motion sensors, such as anaccelerometer and/or gyroscope, can be implemented for detecting afreefall motion or any other external movement of the AMD based onmotion data. The motion data may be associated with movement of the AMDand collected from the one or more motion sensors. For instance, amotion sensor can detect any motion made around or on the AMD, e.g., afreefall motion of the AMD based on the motion data. The term “freefall”may refer to a condition where the object under considerationexperiences substantially unimpeded downward acceleration due togravity.

The motion sensor may detect such a gravitational acceleration of anobject (e.g., AMD) in freefall. When the gravitational acceleration(falling toward the center of the Earth at an acceleration rate of about9.81 m/s²) or a certain acceleration or higher set in the AMD isdetected by the one or more sensors, the AMD determines that there is afreefall motion of the AMD, falling from the top of, e.g., about 1.2-1.5m, to the ground. The motion detection is however not limited to thefreefall motion, but may include other movements, for example, a shake(e.g., left to right movement and/or up and down movement for certaindisplacement for a certain period of time or more), swiping, pinching,tapping, etc. In certain embodiments, when motion or motions have beendetected by the one or more sensors, the AMD may act to stop certainactions or functions of the AMD to prevent damage to internal componentsand/or incorrect delivery of medication (e.g., erroneous dosing). Inaddition, when there is zero output from the accelerometer, thecontroller may determine the freefall motion and thus control theoperation of the AMD (e.g., halt operation as discussed herein).

In some embodiments, the AMD may detect motion or motions via motionsensors in various forms as noted above and may store in motion data. Incertain embodiments, the stored motion data can be used not only formerely detecting a motion of the device such as freefall as describedabove, but also for interaction with users so as to alert the userregarding any potential or actual malfunction of the device and toreceive user acknowledgement of the alert. Therefore, motion datadetected by the AMD can provide useful information both to alert theuser to potential problems and to allow the user to initiate interactionwith the AMD, if the user so chooses. However, it is of particularimportance that the AMD alert the user in a situation where a medicamentis potentially erroneously delivered to a subject/patient which canresult in a critical situation, for example, a situation where the AMDis damaged in a fall, by being dropped, accidentally thrown etc. asdescribed above. In various embodiments as will be described herein, themotion detection can be employed for various uses as further describedbelow.

For example, referring the process 6200 of FIG. 62, when a motion hasbeen detected by one or more motion sensors in the form of motion data6202, the AMD may determine whether the motion is a freefall motion ofthe AMD 6204 as discussed herein. Upon determining that the detectedmotion is in a freefall motion 6202, the operation or functions of oneor more of components of the AMD (e.g., a pump of the AMD) may becontrolled to be paused 6208. As part of step 6208, the AMD may lock thetouchscreen (e.g., disable touchscreen controller to prevent touchinputs) and/or lock the AMD into, for example, a sleep or locked state.As described above, pausing the pump may also pause the medicamentdelivery to the subject. Upon determining that the motion is thefreefall motion, the number of cycles of the pump may be recorded at theinstance when the freefall motion is detected at step 6206. Then, themotor 312 might be ceased to stop or pause the pump operation at step6208 and pause or stop the delivery of medicament to the subject at step6210. In addition, the amount of medicament delivered between the timethe freefall motion was detected and the time delivery of the medicamentwas paused may be also recorded at step 6212. In some cases, the AMD mayexecute steps 6202, 6204, and 6210 upon determining that the AMD is infreefall without recordation of medicament delivery of steps 6206 and6212.

In certain embodiments, the pump of the AMD may have a pump mechanismincluding, e.g., a housing, DC servomotor, a reservoir, cartridges,circuitries, batteries, and the like, which are sensitive to any outsideimpact due to an inadvertent or accidental collision, drop, etc. Thepump mechanism may be adapted to use a general pump mechanism. Theambulatory medicament pump can be any pump that can be used inmedicament pumps known to those of skill in the art, for example, aperistaltic pump but not limited thereto.

Ambulatory Medicament Pump Motor Control

In certain embodiments, as noted above, one or more motion sensors suchas an accelerometer can detect a freefall motion of the AMD based onmotion data, which is associated with movement of the AMD, collectedfrom the one or more motion sensors. For instance, a motion sensor candetect a freefall motion of the AMD based on the motion data and the AMDmay paused or stopped, which may cease operation of medicament delivery.

The term “paused” may refer to stoppage for a predetermined period oftime and may automatically resume operation after a certain period oftime or when a certain condition has met. In some cases, paused caninclude stopping the AMD until the user directs the AMD operations toresume. When the AMD is paused or operation is halted, such as in a casewhere the AMD is halted until further instructed by the user after thedetection of the freefall motion, the delivery of medicament to thesubject can be paused as a result. The halt operation of pausingdelivery of medicament to the subject can be carried out by instructingthe controller to cease rotation of the motor 312 of the ambulatorymedicament pump, by cutting power supply to the ambulatory medicamentpump, or switching from a closed loop circuit to an open loop circuit bycontrolling a switch unit. In some embodiments, the user may be informedvia a user interface (e.g., touchscreen display 504) when the AMD hasstopped operating the pump/motor 212, 312. In some cases, when afreefall motion of the AMD is detected, the AMD may pause the deliveryof the medicament for a period of time. In some such cases, the periodof the time can be one minute, five minutes, ten minutes, thirtyminutes, an hour, or an amount of time defined by the subject.

Alarm Generation Based on AMD Condition

In alternative, or in addition to the cessation of the AMD's internaloperation, an alarm can be outputted in various ways to inform a user.An acknowledgement of the user of the alarm may be required in certainsituations. The alarm may alert the user regarding various conditionsregarding the AMD and may warn the user regarding. For example, thevarious conditions may include potential damage to the system andchanges in medicament parameters, cessation of AMD operation. The alarmconditions may further include instances where the user may be informedregarding either potential or actual changes to the system's operation.In various embodiments, the user interface may be a touchscreeninterface or a non-touchscreen interface, or the wake interface 3220.The user interface may present one or more user-interface screens to auser informing the user of the status of the AMD or to receive a user'sdirect manipulation. The user interface can be implemented via anelectronic device that includes a display and one or more buttons,switches, dials, capacitive touch interfaces, or touchscreen interfaces.

As discussed above, the ambulatory medicament device may include analarm system configured to monitor the ambulatory medicament deviceand/or the subject, and to generate an alarm when it is determined thata condition has been detected that satisfies an alarm condition.

In some embodiments, with reference to FIG. 32, the CCM may includecontrol methods of the AMD implemented to prevent unintended therapychanges by detecting particularly a certain motion of the AMD. Inaddition to the above-described elements, the blood glucose controlsystem that provides blood glucose control via an ambulatory medicamentpump may further include a medicament reservoir (e.g., reservoir 408)configured to store a medicament and from which the medicament can bedelivered to the subject by the pump 212. In some examples, the pump 212can include one or more medicament cartridges or can have the integratedreservoir 408 of medicament. In various embodiments, the operation ofthe pump 212 can be controlled by the controller 400

In some examples, as also noted above, the motion sensor can sense anend of the freefall motion and resume the delivery of the medicamentupon detecting the end of the freefall motion or resume the delivery ofthe medicament after a specifically set period time has lapsed. In thiscase, the user may be notified with the resumption of medicamentdelivery via the user interface, or in certain embodiments, the userinterface may display an option button for the user to accept or declinethe resumption of medicament delivery.

In some embodiments, the AMD may be programmed to record an amount ofmedicament administered to the subject upon detecting the freefallmotion and determine an amount of medicament administered between a timethe freefall motion was detected and a time delivery of the medicamentwas paused. In this manner, the amount of medicament delivered to thepatient between the instance of the freefall motion and the instance ofthe pause may be determined in accordance with therapeutic protocols.The amount of medicament administered to the subject can be determinedfor example based on the number of cycles completed by the ambulatorymedicament pump. The number of cycles can be calculated based on howmany turns the motor 312 has made prior to the stopping of the motor.

As noted above, the AMD may detect an end of the freefall motion. Inresponse to the detection of the end of the freefall motion, the AMD mayresume administering the medicament to the subject based on the recordedamount of medicament by controlling the pump. The end of freefall motionmay be detected by a baseline output of the motion sensor. For example,when the motion sensor includes an accelerometer, the baseline outputmay be the signal output detected by the accelerometer and maycorrespond to the signal output due to gravity when the AMD is at rest.In some cases, the baseline output can be within a range of accelerationvalues surrounding the acceleration of gravity. For example. The rangeof acceleration values can encompass accelerations felt by theambulatory medicament device while attached to the subject.

In some cases, when the motion sensor detects less than the baselineoutput beyond a predetermined freefall threshold signal output, the AMDcan determine the AMD is in free fall motion. For example, when themotion sensor detects zero output, the AMD is in free fall motion. Insome cases, the AMD can determine that AMD is in freefall when theoutput is greater than zero, but less than the predetermined freefallthreshold. When the signal output is greater than the predeterminedfreefall threshold, the AMD can determine that the AMD is not at rest orthat subject is moving the AMD, but that the AMD is not in freefallmotion because the motion sensor provides an output signal between thebaseline output and the predetermined freefall threshold signal output.When the signal output from the motion sensor is between zero and thepredetermined freefall threshold signal output, the AMD can determinethat the AMD is in freefall. In some cases, the predetermined freefallthreshold may correspond to when the AMD has experienced freefallacceleration due to gravity from 2-6 feet, including 3-5 feet, including4-5 feet, including any values in-between.

In response to the detection of an end of the freefall motion, the AMDmay further calculate a jerk of the ambulatory medicament device duringthe freefall motion based on the acceleration and determine whether thejerk exceeds a threshold value. If the jerk does not exceed a thresholdvalue, the AMD may resume administering the medicament to the subject.If, however, the jerk exceeds the threshold value, the AMD may generatean alarm to notify a user, and request that the user acknowledge thealarm in the form of an alarm response signal from the user (orsubject). The alarm may be configured to include an urgency level basedon the calculated jerk. The alarm, and the alarm response signal, may beimplemented in multiple formats. For example, the alarm response signalmay include an alarm snooze signal, which snoozes the alarm, or an alarmacknowledgement signal configured to dismiss the alarm. In certainembodiments, the alarm associated with the highest alarm severity levelhowever may not be snoozed or dismissed. Alternatively, the alarmassociated with the highest severity level may be snoozed for a shortertime period than alarms of lower severity levels, which will bedescribed in more detail further below.

The alarm herein may be generated due to various reasons, e.g., due tothe drop of the AMD as described above, and in addition the motionsensor may detect further motions of the device, and the motion sensormay be further configured to detect the motion of the user responding tothe alarm. That is, the ambulatory medicament device may not only detectthe motion of the device itself as freefall, but may also be configuredto detect the motion of the device by an external impact (e.g., tap,shake, etc.) on the device body.

In addition, another alarm may be generated after a specific period oftime has lapsed, and in this case, an alarm acknowledgement response maybe received, and the alarm may be dismissed. The alarm or alarms can becategorized by the level of intensity, for example, a low-level alarm, amedium-level alarm, or a high-level alarm, that is determined based onthe alarm condition. That is, the alarm may have an urgency level, forexample, between 0 and 5 determined based on the alarm condition, suchthat the alarm can be generated differently based on the level ofurgency associated with the alarm condition. In some examples, the alarmcondition may be an alarm condition in an alarm profile as will bedescribed below in more detail.

For some examples, referring back to FIG. 62, upon determining that themotion is the freefall motion, the number of cycles of the pump may berecorded at the instance when the freefall motion is detected at step6206. Then, the motor might be ceased to stop or pause the pumpoperation at step 6208 to ultimately pause or stop the delivery ofmedicament to the subject at step 6210. In addition, the amount ofmedicament delivered between the time the freefall motion was detectedand the time delivery of the medicament was paused may be also recordedat step 6212.

When the AMD has reached the ground, such that the freefall motion isended, the sensor can also detect and may generate an alarm. FIG. 63 aflow diagram 6300 illustrating an example procedure to control anoperation of an ambulatory medical device pump after freefall motion hasended. Once the end of freefall motion is detected at step 6302, the AMDmay calculate a jerk at step 6304. The jerk or jolt, corresponding to arate at which an object's acceleration changes with respect to time. Itis a vector quantity (having both magnitude and direction). The jerk orjolt can be associated an impact on the AMD as a result of, for example,contacting the ground or some other object after freefall motion withthe impact generating forces or acceleration values on the AMD greaterthan an alarm and/or diagnostic threshold step 6306. In some cases, thejerk or jolt can occur without freefall motion. For example, the jerk orjolt may be determined because the AMD was hit or bumped against anobject that resulted in an impact generating forces or accelerationvalues on the AMD greater than the alarm and/or diagnostic thresholdstep 6306.

The AMD then may output an alarm if the calculated jerk is equal to orgreater than an alarm and/or diagnostic threshold at step 6308. Thealarm and/or diagnostic threshold rate may be used as criteria indetermining whether the alarm condition is satisfied by comparing statusinformation (e.g., calculated jerk) to one or more alarm thresholds(e.g., reference jerk that is preset or predetermined jerk threshold) oralarm conditions. The alarm threshold and alarm profile will be furtherdescribed in detail in the Alarm Condition section.

An alarm can be generated to inform the user 6308 of a malfunction orsome other condition of the AMD as result of the jerk. In some cases,the user may be required to acknowledge the alarm 6312. Once the alarmacknowledgement has been received from the user at step 6312, the AMDand/or motor operation may be resumed to continue the delivery ofmedicament to the subject at steps 6314 and 6316. The alarmacknowledgement will be described in more detail in the Motion-BasedAlarm Acknowledgement of User section. If the jerk is on the other handthe alarm less than the alarm and/or diagnostic threshold, the AMDand/or motor operation may be resumed to continue the delivery ofmedicament to the subject at steps 6314 and 6316 without generatingalarms or running a diagnostic test.

In addition or in alternative to generating an alarm, when thecalculated jerk is equal to or greater than the alarm and/or diagnosticthreshold, a diagnostic test may be performed to check the condition ofthe pump at step 6310. The diagnostic test can be employed as a standardfor determining whether to resume the administration of the medicamentto the subject. If the AMD does not pass the diagnostic test, e.g.,fails to meet specific requirements set for determining whether toresume the administration of the medicament to the subject based on oneor more operating parameters, the AMD or one or more components of theAMD may be considered as being damaged or any of the controllerscontained therein may be determined to have a malfunction. In this case,an alarm may be generated informing the user of the damage or the likeof the AMD and step 6308 may be performed. On the other hand, if thediagnostic test is passed, the pump operation may be resumed to resumethe delivery of medicament to the subject at steps 6314 and 6316.

Alternatively, or in addition to providing the alarm, when the AMD isdetermined to be malfunctioning (e.g., damaged), the AMD may be reset byrestarting the device. The AMD may either automatically restart ordirect the user to restart the AMD (e.g., as part of an alarmcondition). If restarting the device resolves the malfunction issuescaused by the jerk, the AMD may resume pump operation and medicamentdelivery steps 6314, 6316. In some cases, upon restart, the diagnostictest may be performed and/or the alarm generation process may beperformed again. In some cases, if the AMD does not pass a diagnostictest for the second time after restarting, the AMD may generate an alarm6308 informing the user that the AMD is damaged and needs to berepaired. Such an alarm may be a high severity alarm as discussedherein. In some cases, the AMD may generate other alarms discussedherein while resuming operation 6314, 6316. The other alarms may informof some malfunction of the AMD that does not require immediateresolution in order for the AMD to resume operation 6314, 6316.

In some cases, the AMD can generate an alarm when the AMD cannot verifythe amount of medicament delivered due to the subject. For example, theactual amount of medicament delivered by the AMD may be determined orcalculated based on the amount a dispending screw has been turned by thepump motor to dispense medicament from the cartridge. In some case, theactual amount of medicament delivered by the AMD can be determined basedon flow sensors and corresponding outputs indicating the amount ofmedicament dispensed. In some case, the actual amount of medicamentdelivered by the AMD can be determined based on the amount of volumeremaining or volume change of medicament in the cartridge.

The AMD can also determine how much medicament was supposed or desiredto be delivered to the subject based on an algorithm for deliveringglucose control therapy as discussed herein. When the AMD determinesthat the medicament actually delivered does not match or is not the sameas the medicament that was supposed or desired to be delivered based onthe glucose control therapy protocols, the AMD may generate an alarm asdiscussed herein. In some cases, the alarm generated because the AMDcannot verify actual versus desired medicament delivery can be part ofthe generate alarm 6308 and/or diagnostic test 6310 steps as discussedherein. In some cases, the alarm generated because the AMD cannot verifyactual versus desired medicament delivery can be part of other alarmgeneration as discussed herein. For example, the AMD may generate analarm regarding the error in medicament delivery during operation afterresumption of pump operation and medicament delivery 6314, 6316.

The method described herein may be performed by an AMD (e.g., by one ormore processors of the AMD) to detect AMD device malfunctions, generatecorresponding alerts, and prioritize the alerts to enable the subject oruser to quickly and easily determine whether the device malfunction willimpact therapy, and should be immediately addressed. In some cases, themethod of device malfunction alert prioritization may be used by othersystems.

Motion-Based Alarm Acknowledgement

Certain alarms, such as informational alarms, may be dismissible.However, generally the alarm may remain on the alarm list until thecondition that caused the alarm is acknowledged and resolved.

A user may be able to acknowledge and/or snooze alarms via a userinterface. In some examples, in order to acknowledge and/or snoozealarms, the user may first need to activate the user interface and thenprovide a gesture to unlock the user interface. For example, the usermay use the wake button to activate a touchscreen display and thenprovide a gesture on the screen to unlock display. In some embodiments,the touchscreen display may be configured to allow the user or subjectto navigate directly to the issue or fault for which an alarm is beingdelivered. This capability provides the user with more direct access toaddress the fault causing the alarm, so that the fault may be addressedmore easily, and the alarm may then be stopped.

Acknowledging the alarm may include an action to respond to the alarmsuch that the user can resolve the alarm. For example, resolving thealarm may include replacing an insulin cartridge, changing a site wherethe ambulatory medicament device is connected to the subject, charging abattery of the ambulatory medicament device, providing insulin or acounter-regulatory agent to the subject and/or the ambulatory medicamentdevice, replacing a damaged AMD or motor due to dropping thereof, or anyother action that may be performed to address an alarm condition. Insome cases, the resolution action may be acknowledging the alarm. Forexample, if the alarm is informational (e.g., to inform the user thatmore insulin has been ordered or to inform that the AMD is notfunctioning properly), acknowledging the alarm may be a sufficientresolution action.

Referring to FIG. 64, which is a flow diagram 6400 illustrating anexample procedure to receive an alarm acknowledgement from a user, whenthere is an active alarm detected due to various errors detected such aserror in the AMD, error in medicament measurement, etc. In someembodiments, an alarm condition can be detected at step 6402 and analarm can be generated based on the alarm condition (e.g., severity orurgency level of the alarm as described herein) at step 6404. The alarmcan be generated to notify the user of the current situation oroperation status of the AMD. The user may be then requested toacknowledge the alarm to make sure that the user is aware of the currentalarm and associated operating conditions of the AMD at step 6406. Thealarm acknowledgement can be done in various ways, e.g., touching ortapping (one or more taps on one or various locations) on thetouchscreen or touching or tapping on the AMD, shaking the AMD, shakinga hand above the touchscreen, swiping on the touchscreen, pressing thewake button or any other implemented button (as a touchscreen orphysical button), etc. The alarm acknowledgement will be described indetail later in this section.

Upon receiving a response from the user at step 6408, 6410 to snooze thealarm, the alarm may be snoozed or silenced 6412. In some cases, thealarm may be snoozed for a specified or predetermined period of time at6412. In some cases, the alarm may be dismissed 6420 when the alarm isacknowledged and the alarm condition is determined to have a low urgency(e.g., level 0-2, including level 1). In some cases, the alarm may bedismissed 6420 when the alarm is not acknowledged or snoozed, but thealarm condition is determined to have a low urgency (e.g., level 1). Thelow urgency alarm may be generated 6406 and after not detecting an alarmresponse from the user, the alarm may be dismissed 6420 with low urgencyalarms. In some cases, the alarm may be snoozed 6412 when the alarm isacknowledged (and not snoozed by the user when the option to snooze isprovided), but the alarm condition is determined to have a higherurgency (e.g., level 2) that merits generating a second alarm 6416 asdiscussed herein. The AMD can generate user interface screens asdiscussed herein to provide an option for the user to snooze an alarmand/or acknowledge the alarm. Whether the user can snooze and/oracknowledge the alarm can be determined based on the urgency of thealarm as discussed herein.

When the alarm has been snoozed at step 6412, the AMD may add the alarmcondition to a list of alarms as discussed herein. After the alarm hasbeen snoozed 6412, the AMD may start a timer to track the passage oftime. After a predetermined period of time has passed, the AMD cangenerate a second alarm at step 6414 to notify the user that the alarmcondition still exists. When the AMD detects 6416 that the user hasacknowledged the second alarm, the alarm can be then dismissed at step6418. Alternatively, if an alarm snooze response is received from theuser or the user again does not acknowledge the alarm 6418, the snoozefunction may be performed again for a predetermined period of time(6412) to generate additional alarms (e.g., second alarms) until thealarm condition is dismissed by the user or resolved as discussedherein.

In some embodiments, the one or more user interface screens configuredas a touchscreen may provide a graphical display including informationabout an alarm when an alarm threshold or condition is reached orexceeded as discussed herein. The one or more user interface screens maybe an alarm acknowledgement touch user interface element. The one ormore user interface screens may be configured to receive an alarmacknowledgement signal from the user via the touchscreen. Then, the oneor more user interface screens may include resumption of administeringthe medicament to the subject based on the alarm acknowledgement signal.

In some embodiments, when the magnitude of a measured jerk exceeds athreshold, the AMD may be configured to resume operation after the useracknowledges the alarm. The graphical display can be arranged andcolored based on an urgency level of the alarm condition. For example,the alarm condition having the highest urgency level may be colored inred and displayed at the top of the screen. The alarm condition havingthe lowest urgency level may be colored in green at the bottom of thescreen for the user to easily discern therebetween. The color and thelocation herein are merely examples but can be any color and anylocation (e.g., upper right corner, middle, or the like on the screen).

Further, the graphical display is not limited to the visual display, butcould be in the form of sound, by, e.g., a speaker generating audiblesignals based on the level of the urgency. The audible signal mayinclude one of, e.g., a beep, a series of beeps, a patterned beeping, ora speech output describing the alarm. The volume and the play length ofthe audible signal may vary based on the level of urgency (e.g., playingfor one minute for the highest urgency while playing for 10 seconds forthe lowest urgency).

In addition, or alternatively, the ambulatory medicament device mayinclude a haptic motor allowing a haptic alarm signal to be generatedtherethrough based on an urgency of the alarm condition. The hapticalarm signal may include, e.g., a sustained vibration, a burstvibration, or a vibration pattern. Similarly, the length or intensity ofthe vibration may vary based on the urgency level of the alarm.

In some embodiments, when a motion is detected, an alarm condition canbe detected before generating an alarm. An alarm response from thesubject can be detected based on the motion data of the user todetermine whether to silence the alarm. The motion data here may includean acceleration of the ambulatory medicament device or touch inputs ontouchscreen caused by the alarm response. The alarm response may be aseries of taps, e.g., a single tap, a double tap, multi-tap, or amulti-location tap on a body and/or touchscreen of the ambulatorymedicament device or a shaking of the ambulatory medicament device(refer to FIG. 64). However, the alarm response is not limited to thetaps or shaking. The alarm response may include any other motions orlevels of motion (e.g., soft tap, soft shaking, a different number ofshakings, etc.) can be implemented. The alarm response may be furtherdetermined whether it is an alarm snooze response or an alarmacknowledgement response. Accordingly, when the alarm response isdetermined to be the alarm snooze response, the alarm may be snoozed fora specific period of time which may vary based on an urgency level ofthe alarm. For example, a low urgency alarm (e.g., level 1) may besnoozed for a longer predetermined period of time relative to theshorter predetermined period of time of a high or higher urgency alarm(e.g., level 2).

Referring back to FIG. 64, an alarm can be generated based on an urgencylevel. For instance, when an alarm condition is detected at 6402, theurgency level as described above may be determined and the alarm can begenerated based on the determined urgency level 6404. In some examples,for an alarm having a higher urgency level may be generated in redcolor, a louder sound or a sound in a longer period of time (e.g., 1minute), higher vibrations, etc., than an alarm having a lower urgencylevel which may be generated in yellow color, a softer sound, a sound ina shorter period of time (e.g., 10 seconds), softer vibrations, etc., soas to distinguish the alarms. Once the alarm has been generated based onthe urgency level, the user may be required to acknowledge if theurgency or priority level is above a certain level. The period of timehowever can vary based on the urgency level, for example, snoozed for 1minute for a lower urgent alarm and snoozed for 5 seconds for a higherurgent alarm, at 6412. The user is then again requested to respond tothe alarm to confirm that the user is aware of the alarm. In some cases,the user may not be able to snooze the alarm if the alarm is above acertain urgency level (e.g., level 3-5 alarms).

As noted above, a user may be able to acknowledge and/or snooze alarmsvia a user interface. In some examples, in order to acknowledge and/orsnooze alarms, the user may first need to activate the user interface(e.g., by providing a wake action) and then provide a gesture to unlockthe user interface. For example, the user may use the wake button ortouch input on the AMD to activate a touchscreen display and thenprovide a gesture on the screen to unlock display. Unlocking the displaywill be further described below in detail. In some examples, thetouchscreen display may be configured to allow the user or subject tonavigate directly to the issue or fault for which an alarm is beingdelivered. This capability provides the user with access to address thefault causing the alarm so that it could be corrected thereby stoppingthe alarm.

In some cases, a user may be able to acknowledge and/or snooze alarmsvia motion sensor. As described herein, the AMD may include a motionsensor that detects motion or acceleration of the AMD or on the AMD(e.g., tapping or shaking gestures). The motion sensor can include anaccelerometer, gyroscope, and/or other electrical or mechanical motionsensors that convert motion or acceleration into electrical signals. Insome examples, the user may tap on the AMD to acknowledge and/or snoozealarms. In some examples, the user may acknowledge and/or snooze alarmsvia the motion sensor without the AMD activating one or more userinterface modules such as the touchscreen display. In some examples, theuser may acknowledge and/or snooze alarms via the motion sensor withoutactivating the user interface (e.g., without providing a wake action).The motion sensor may be configured to detect different tap patterns(e.g., a single tap, a double tap, etc.). Each tap pattern may beassociated with a different function. In some cases, the AMD can includea user interaction sensor which may include any motion sensor(s) and/orany one of the user interface modules such as the touchscreen or thewake interface. The user interaction sensor can convert electrical ormechanical properties of the user into electrical signals. Theelectrical signals from the user interaction sensor can be userinteraction signals. In some cases, user interaction signals canencompass both user input via a touchscreen and user interaction via amotions sensor as discussed herein.

A user may interact with the alarms generated based on the alarmcondition. In some cases, the user can only interact with the alarmswhen the AMD and/or the user interface is unlocked. In some cases, theuser can interact with the alarms to snooze them or to obtain furtherinformation, when the AMD is locked. However, the user may not be ableto dismiss the alarm without unlocking the ambulatory medicament device.The user may not be able to dismiss the alarm without unlocking theambulatory medicament device when the alarm is urgent and requires userattention. Interacting with the alarms may include providing informationassociated with the alarm to a user in response to the user interactingwith the alarm, or an indicator representative of the alarm.

In some cases, the AMD can determine that alarm condition requiresurgent user attention based on, for example, a severity level of thealarm as discussed. When the alarm condition requires urgent userattention, the AMD can prevent or not allow the alarm to be snoozed viafor example taps or other user interactions as discussed herein. In somecases, in response to determining that the alarm requires urgent userattention, the AMD can deactivate or exit a power saving mode into, forexample, a wake mode.

In some cases, in response to snoozing the alarm, the AMD may update thealarm condition or alarm information with snoozed status, such asupdating the one or more alarm status indicators to indicate that aparticular alarm has been snoozed. For example, the alarm statusindicators may include or be changed to alarm status icons that indicatean alarm condition has been snoozed.

In some cases, the AMD can move or add the snoozed alarm statusindicators to a list of pending alarm conditions. The list of pendingalarm conditions can include indications, or the alarm status iconsassociated with the alarm status indicators that indicate the alarmcondition has been snoozed. Adding the snoozed alarm status indicatorsor alarm status icons to the list of pending alarm conditions can bepart of the step of no longer displaying the one or more alarm statusindicators on the display in response to the alarm being snoozed. Forexample, the AMD may not display the list of pending alarm conditions(which can include snoozed or as well as non-snoozed alarms) on analways one screen in a power saving mode of the AMD. The list of pendingalarm conditions may then be later access via user input/interactionwith AMD or for example, when entering the wake mode. In some cases, analarm that was dismissed as discussed herein may be added to the list ofpending alarm conditions. The dismissed alarm may include a statusindicator that indicates that the alarm was dismissed.

In some embodiments, when there is an existing alarm or alarms to beresolved, the touchscreen may not be unlocked until the active alarm isresolved. Once a user acknowledges or resolves the alarm, or the issuecan be resolved automatically (e.g., when the AMD was in a freefallmotion but there is no error in the medicament delivery after thefreefall motion is ended), the user can awake the touchscreen by motionas described above and a home screen can be displayed on thetouchscreen. Waking up and unlocking the touchscreen by motion will bedescribed hereinafter.

Motion-Based Wake of AMD

In certain embodiments, referring back to FIG. 32, a user 3226 may wakethe AMD from a sleep state or unlock the AMD by interacting with a wakeinterface 3220. In certain embodiments, the user 3226 may wake the AMDfrom another state or mode, such as for example a power saving mode orlow power mode, the AMD by interacting with a wake interface 3220. Whenthe AMD is in a sleep state or other state/mode, the touchscreencontroller may not receive user input or user input signalscorresponding to user input (e.g., via a touchscreen display 3222). Whenthe AMD is in a sleep state or other state/mode, the touchscreencontroller may not receive user interaction or user interaction signalscorresponding to user interaction (e.g., via device sensors 3208,including an accelerometer or other motion sensors).

Waking the AMD may include activating a touchscreen interface orpresenting a lock screen to a user. Further, waking the AMD may includewaking the touchscreen controller such that it can receive user input oruser input signals corresponding to user input. The wake interface 3220can include one or more of the additional user interfaces mentionedabove that are configured to generate and provide a wake input (or wakesignal) to the CCM when detecting a pre-set user interaction.Alternatively, or in addition, the wake interface 3220 can be any typeof wake interface element of the AMD that a user can interact with towake at least a feature (e.g., a touchscreen interface) of the AMD. Insome cases, the AMD may wake in response to detection of a particularmovement or motion. For example, a determination that the ambulatorymedicament device is being moved with a particular motion may cause theAMD to awaken or cause the AMD to awake the touchscreen interface of theAMD. In some cases, the AMD may wake in response to detection of atapping on the AMD, such as a single tap or a double tap. In someembodiments, a single tap or a double tap may activate one or moreelements of the user interface module 3218, such as for example thetouchscreen display 3222. The touchscreen display can be a touchdigitizer that converts analog interactions of the user (e.g., viaelectrical or mechanical properties of the user) into digital signalscommunicated to one or more controllers as discussed herein.

The tap control or other gesture control of the AMD may be contextsensitive. For example, the AMD's response to gesture controls maydepend on whether there are any active alarms. In some cases, when thereare no active alarms, a single and/or double can turn on or off (toggle)the touch screen. As another example, in the locked state with an alwayson screen, a single and/or double can turn on or off (toggle) thebacklight.

The context sensitive response of the AMD to user inputs can also betime dependent. For example, when a user snoozes or acknowledges analarm as discussed herein, if a certain amount of time since snoozing oracknowledging is less than a predetermined context time threshold, theAMD may respond to gesture user inputs (e.g., taps) as discussed hereinas if there are no active alarms (even though an alarm may have beenrecently snoozed and/or acknowledged), such as for example toggling thetouchscreen and/or backlight. After more time than the predeterminedcontext time threshold has passed, the AMD may respond to gesture userinputs (e.g., taps) to change and/or display alarm conditions asdiscussed herein.

When in the wake and/or unlocked state, a user may interact with thetouchscreen display 3222, alphanumeric pad, or other types of userinterfaces that may be included in the user interface module 3218. Theuser interface module 3218 may include any combination of one or more ofthe touchscreen display 3222, alphanumeric pad, or other types of userinterfaces.

In some examples, a device sensor 3208 may be a sensor that generates asignal or status value associated with the condition of modules,interfaces, accessories, disposables of the AMD. In some examples, adevice sensor 3208 may generate a signal that corresponds to a parameterassociated with a component in a module or interface. For example, onedevice sensor may record the voltage of a battery and another devicesensor may record the follow rate of a pump the medicament deliveryinterface 3214.

In some examples, the alarm system 3202 may implement procedures forallowing the user or subject to change the alarm settings and/oracknowledge an alarm annunciation via the user interface module 3218. Insome examples, the user may be able to see one or more alarmsannunciated on a user interface (e.g., as a list of alarms), even whenthe AMD is in a locked state. In these examples, the user may not beable to acknowledge or respond to alarms when the AMD is in the lockedstate.

In certain embodiments, the user or subject may access an alarm settingscreen or acknowledge an alarm annunciation by providing a wake actionor a wake action followed by a first gesture via, for example, thetouchscreen display 3222. In some cases, the first gesture may becreated by shaking the AMD, inputting a swipe gesture on thetouchscreen, pinching the AMD, or tapping one or more times on aspecific location of the AMD (e.g., a single tap, a double tap,multi-tap, a multi-location tap, sequentially or non-sequentially, on anupper left corner, a lower right corner, or the like of the AMD or thepump). In some cases, touching three corners of the AMD can power on oroff the AMD.

In some examples, user interactions may include the selection of anicon, a series of taps or inputs, one or more gestures (e.g., a linearswipe, an arcuate swipe, a circular swipe, or other simple or complexmovement across the touchscreen), performing a pattern or sequence onthe touchscreen (e.g., drawing an image), a multi-touch or multi-inputinteraction, a combination of the foregoing, or any other type ofinteraction with a touchscreen, or portion thereof. The series of inputsmay be any combination of touch movements, touch points, numericalcharacters, alphabetical characters, and other symbols. Gestureinteractions can be guided by visual indicia displayed or printed on theAMD. In some embodiments, the visual indication can include animationsthat suggest or guide user interactions with a touchscreen. For example,the first user interaction can include an arcuate swipe around at leasta portion of a generally circular icon or logo. In some examples, thefirst and/or second user interactions may include a predeterminedsequence of numerical and/or alphabetical inputs. In some examples, aseries of multiple inputs, the range of parameters for an input may bedependent on other inputs in the series. For example, required startposition of a touch movement may be dependent on the position of theprevious touch movement. The time that the series of inputs are enteredmay also be a part of the range of parameters. For example, a series ofinputs may need to be entered in no less than 3 seconds or more than 3seconds, and no more than 15 seconds or less than 15 seconds.

In some embodiments, a user may be asked to enter a passcode or passwordto unlock the touchscreen, or, after the touchscreen display has beenactivated by the wake signal, a passcode may be required to unlock thetouchscreen display. The user may enter a security code into the AMD oran intermediary device that the AMD and/or the intermediary device mayvalidate or verify matches the passcode to access certain functions ofthe AMD. In some examples, the passcode or password can be entered inthe form of motion, such as a series of taps or inputs, one or moregestures (e.g., a linear swipe, an arcuate swipe, a circular swipe, orother simple or complex movement across the touchscreen), performing apattern or sequence on the touchscreen (e.g., drawing an image), amulti-touch or multi-input interaction, a combination of the foregoing,or any other type of interaction with a touchscreen, or portion thereof.Alternatively, a keypad may be used to enter a passcode for unlocking auser interface.

Referring to process 6500 of FIG. 65, when the AMD or a touchscreen ofthe ambulatory medical device is in a locked state or sleep state, auser can wake up the touchscreen by motion in various forms. When amotion of a user or a motion (e.g., tap on the AMD or movement of theAMD) of the ambulatory medical device is detected at 6502, theambulatory medical device checks determines whether there is an activealarm to be resolved at 6504. When there is no pending alarm, thetouchscreen may become active at 6506. In some cases, where thetouchscreen display is off in the locked or sleep state, the AMD mayturn on the touchscreen at step 6506. Depending on the gesture or othercontext sensitive criteria of the AMD operation such as whether it isnighttime, the AMD may turn on the backlight as part of step 6506. TheAMD may also unlock the touchscreen 6508 and enter into an active modein response to the motion detected 6502, depending on for example thetype of motion detected, and for example display a home screen. Forexample, a single tap can turn on step 6506 the touch screen. A doubletap can turn on 6506 the touchscreen and unlock the touchscreen 6508. Insome cases, where the touchscreen is displaying an always on interfacein the locked or sleep state, the AMD may wake 6506 and unlock thetouchscreen 6508.

In some cases, if there is an active alarm, a user may be requested toacknowledge the alarm (step 6406 of FIG. 64) or perform an action toresolve the alarm as discussed herein. In some cases, the AMD maydisplay a list of pending alarm conditions as discussed herein. As partof step 6406, the AMD may wake and/or unlock the touchscreen asdiscussed herein for steps 6506 and/or 6508.

In various embodiments, the AMD can receive a touch input directly froma user via a user interface configured as a touchscreen. The touch inputcan be made in various ways, for example, a user can tap on thetouchscreen, a single tap, a double tap, multi-tap, a multi-locationtap, a pinch gesture, or a swipe gesture, or can touch with one or moretouches on one or more corners of the touchscreen. The user can touchthe touchscreen in the form of any of the above-described touch input orany other touch input to unlock touchscreen. For instance, a computingprocessor of the AMD may be configured for locking the device, and whena touch input is detected on any portion of the touchscreen, theprocessor may wake the touchscreen by displaying a home screen. Thetouch input could be a gesture password for unlocking the touchscreen.The computing processor may include a motion sensor detecting touchgestures performed at any location on the touchscreen. The computingprocessor may add a distinct input value associated with each identifiedtouch gesture to an input buffer to form a series of input values. Theseries of input values in the input buffer may then be compared to aseries of values corresponding to a predetermined touch gesture passcodesequence. The touchscreen may be unlocked when the series of inputvalues in the input buffer matches the series of values corresponding tothe predetermined touch gesture passcode sequence. When the touchscreendoes not receive any input for a certain period of time, the touchscreenmay enter a locked state until the user attempts a touch input to thetouchscreen. In various embodiments, at ouch input may include one ormore touches on one or more locations on the AMD (e.g., front, sides, orrear of the AMD).

In certain embodiments, if an incorrect gesture password has beenrecognized a set number of times, the touchscreen may be locked for acertain period of time or a secondary identification may be required,e.g., an identification code may be sent to a user's phone or via emailfor security.

When there is no alarm pending, the touchscreen can be unlocked with orwithout the gesture password check and a home screen may be displayed onthe screen. In addition, when the user attempts to unlock thetouchscreen, the touchscreen may display a touch user interface elementfor user to touch.

For example, referring to the process 6600 of FIG. 66, when a motion isdetected (step 6602) while the AMD is in a sleep mode as described abovein reference to FIG. 65, the touchscreen can become active upondetermining there is no pending alarm at steps 6604, 6606. As part ofstep 6606, the AMD may perform actions and functions discussed herein inreference to steps 6506 and 6508 discussing FIG. 65.

In some cases, if there is an active alarm, the process may go back tostep 6406 of FIG. 64 to request a user to acknowledge the alarm orperform an action to resolve the alarm as discussed herein. In somecases, the AMD may display a list of pending alarm conditions asdiscussed herein. As part of step 6406, the AMD may wake and/or unlockthe touchscreen as discussed herein for steps 6506 and/or 6508 inreference FIG. 65.

In some cases, a password input to unlock the touchscreen may berequested at step 6608 after waking the touchscreen in step 6606. A usercan enter a predetermined password in various ways, including usergesture control inputs such as tapping, shaking, etc., as describedabove, to unlock the touchscreen based on user motion at step 6610. Ifthe motion of the user, as a gesture password input, matches at step6612 with a stored password that is prestored and authorized, the screenmay be unlocked at step 6614. If an incorrect gesture password has beenentered, the touchscreen may become locked or return to the sleep orlocked state. In some cases, if an incorrect gesture password has beenentered more than a set number of times may become locked for aredetermined period of time. In some cases, a further verification maybe required to unlock the touchscreen and/or AMD in order to access theAMD. Examples of password generation are disclosed in U.S. Pat. No.11,103,638, the entire contents of which are incorporated by referenceherein and made a part of this specification.

In some examples, a user may be able to acknowledge and/or snooze analarm via a user interface. In some examples, in order to acknowledgeand/or snooze alarms, the user may first need to activate the userinterface (e.g., by providing a wake action) and then provide a gestureto unlock the user interface. For example, the user may shake the AMD orpick up the AMD to activate a touchscreen display and then provide agesture on the screen to unlock the display. In some embodiments, thetouchscreen display may be configured to allow the user or subject tonavigate directly to the issue, fault, or alarm condition for which analarm is being delivered. This capability provides the user with moredirect access to quickly address the fault causing the alarm so that itmay be addressed, thereby increasing the convenience of the user, andsimplifying the process whereby the user addresses the cause of thealarm.

In some embodiments, the ambulatory medicament device may receive thetouch input via the touchscreen as noted above and determine whether analarm is active upon receiving the touch input. If it is determined thatthere is no alarm, the touchscreen may be unlocked to receive the user'stouch input command. Here, the touch input can include various forms theuser input, e.g., a single tap, a double tap, multi-tap, amulti-location tap, a pinch gesture, a swipe gesture, or the like. Inaddition, the touch input can be performed on any portion of thetouchscreen including one or more corners of the touchscreen. Thelocation of the touch input may be recognized as a different usercommand, e.g., when an upper right corner is touched, the input may beinterpreted as an attempt to, e.g., increase the volume or brightness ofthe screen. The touch input can further include one or more touches atdifferent locations of the touchscreen. Based on the touch inputdetected, the touchscreen and the ambulatory medicament device can beunlocked.

Motion-Based Control of Medicament Delivery

In certain embodiments, a user motion input may be used for release ofdelivery of a bolus medicament dose or other medicament or therapydelivery. As noted above, the motion input can be any form of gesturemade to one or more locations on the ambulatory medicament device (e.g.,a single tap, a double tap, a triple tap, a multi tap, a multi-locationtap, a pinch gesture, or a swipe gesture). The motion can be detected byvarious sensors such as an accelerometer as described above, acapacitive touch sensor, a resistive touch sensor, an infrared andsurface acoustic wave (SAW) touch sensor, etc. as previously describedin detail regarding the motion detection.

When a specific motion of a user has been recognized, the user may beasked to confirm the delivery of the medicament dose by requesting asecondary input. The request may be made on the touchscreen or through aspeaker, a haptic motor generating a vibration, or any other form thatcan alert the user. In some embodiments, a blood sugar level of thesubject may be continuously monitored in real time to determine whetherthere is a need for the bolus medicament dose based on the blood sugarlevel. When the need for the bolus medicament dose is confirmed, thetouchscreen may display a menu option for the user to enter a touchinput to initiate the medicament bolus dose. Accordingly, it is possibleto promptly adjust therapy as desired to secure a sufficient supply ofmedicament to the subject. In addition, the medicament therapy regimencan be managed quickly without any delay in delivery of an appropriateamount of medicament, for example, by adjusting food intake dose orbolus based on the need.

FIG. 67 is a flow diagram illustrating an example process 6700 todeliver medicament to a subject by motion control. That is, FIG. 67illustrates alerting a user of medicament delivery need or when changein the medicament delivery is demanded. For instance, the AMD maymonitor a glucose level of a user at 6702 in real time. In someexamples, the AMD may include a subject sensor 3216 (refer to FIG. 32)that generates a signal or status value associated with one or morephysiological indicators (or parameters) of a subject (e.g., heart rate,blood pressure, body temperature, level of blood glucose, serum levelsof various hormones or other analytes).

In some such examples, the subject sensor can be a continuous glucosemonitoring sensor (CGS). The device and subject monitoring systeminterface 3210 may continuously receive and analyze signals from devicesensors 3208 and subject sensor 3216 to determine the condition of theAMD, the subject, a sensor, and/or other accessories. In some examples,a subject sensor 3216 may be any sensor that generates a signal orstatus value associated with one or more physiological indicators (orparameters) of a subject (e.g., heart rate, blood pressure, bodytemperature, level of blood glucose, serum levels of various hormones orother analytes). In some such examples, the subject sensor can be acontinuous glucose monitoring sensor (CGS). The device and subjectmonitoring system interface 3210 may continuously receive and analyzesignals from device sensors 3208 and subject sensors 3216 to determinethe condition of the AMD, the subject, a sensor, and/or otheraccessories.

Upon determining that there is a need for a bolus medicament dose orchange in bolus medicament dose is desired at step 6704 based on glucoselevels of the user or other parameters of the glucose control therapy,the user may be prompted to initiate the medicament dose delivery atstep 6706. The user can acknowledge or initiate the medicament dose byproviding a specific motion at step 6708 as the user gesture controlmotion. The motion can include various predetermined motions describedherein that correspond to a user gesture control motion for the AMD inthe context of bolus delivery. In some cases, when the user motion ofmedicament delivery initiation has been detected, an additional userinput request may be prompted for confirming the medicament delivery atstep 6710.

At step 6712, the user may input a second or another motion as usergesture control motion to confirm that the medicament should bedelivered. The confirmation of the medicament delivery can be done bythe user inputting a specified motion (tap, touch, swiping, etc.). Inaddition, the tap motion may be a series of taps, e.g., a single tap, adouble tap, multi-tap, or a multi-location tap on a body and/ortouchscreen of the ambulatory medicament device or a shaking of theambulatory medicament device.

The confirmation motion input of the user at 6712 may the same as theuser gesture control motion input at 6708. In some case, theconfirmation motion input of the user at 6710 may be different from theas the user gesture control motion input at 6708. Once the confirmationmotion is received at step 6712, the AMD may release the medicamentdelivery to the subject (e.g., user) at step 6714 based on glucoselevels of the user or other parameters of the glucose control therapy.

The user input request discussed herein, including in reference to FIG.67 for steps 6708 and 6712 may be prompted or requested in various ways.For example, the AMD may include a speaker configured to generate audioprompts. In this case, when a motion or touch input has been detected atstep 6708, a sound may be generated via the speaker to alert the user.The sound may be a beep, music, or any other audible signals to alertthe user. Such that, a person having a vision problem may be aware ofthe request to enter an input. However, it is not limited thereto suchthat the AMD may include a touchscreen controller configured to outputdisplay signals configured to generate user interface screens on atouchscreen and to receive user input signals corresponding to userinteraction with the touchscreen. In this case, a visual signal may beprompted the user to confirm the medicament dose. The AMD may include ahaptic motor configured to generate vibration signals on a body of thesubject. In this case, in response to detecting the touch input ormotion at step 6708, a vibration signal may be generated to prompt 6710the subject to confirm the medicament dose at step 6712. When any one ofthe described requests has been prompted (e.g., sound, vibration,visual, etc.), the user can confirm the medicament dose by providing atouch input or gesture motion as specified at step 6712.

The process 6700 can be applied for various situations, e.g., when aneed to initiate the medicament delivery is detected as described above(e.g., high blood glucose level or bolus based on food intake). In somecases, the process 6700 can be used with administration of othermedicament such as glucagon, where AMD determines glucagon delivery isdesired and prompts the user to initiate and/or confirm delivery ofglucagon. In addition, the process 6700 can be applied to a situationwhen a sudden change in the medicament dose is detected or a change inmedicament dose setting is desired. The user can simply accept thechange or initiate the medicament dose delivery by providing a specificmotion as discussed herein.

In some examples, ambulatory medical devices allow subjects the freedomto treat themselves with an automated blood glucose control system. Theautomated blood glucose control system may automatically provide insulinand/or a counter-regulatory agent (e.g., glucagon) to a subject to helpcontrol the blood glucose level of the subject. Generally, a controlalgorithm is implemented by an automated blood glucose control system(BGCS) to determine when to deliver one or more glucose control agentsand how much agent to provide to the subject. Further, the controlalgorithm may control both an ongoing or periodic delivery of insulin(e.g., a basal dose), and a correction bolus that may be provided toadjust a subject's blood glucose level to within a desired range. Thecontrol algorithm may use blood glucose level readings obtained from asensor, such as a continuous glucose monitoring (CGM) sensor, thatobtained automated blood glucose measurements from the subject.

In some cases, the automated blood glucose control system may receive anindication of insulin or medicament to administer to a subject in placeof an automatically calculated dose of insulin. For example, theautomated blood glucose control system may receive an indication that asubject is consuming or will consume a meal. The indication may includea type of meal to be consumed (e.g., breakfast, lunch, or dinner) and anestimate of the quantity of food or carbohydrates to be consumed (e.g.,less than usual, a usual amount, more than usual, 30-40 grams ofcarbohydrates, 45-60 grams of carbohydrates, etc.). Based on theindication, or meal announcement, the automated blood glucose controlsystem may calculate an amount of insulin to administer to the subject.The calculation may be based on an insulin to carbohydrate ratioprovided by a clinician and/or determined by the automated blood glucosecontrol system.

Insulin may be administered subcutaneously into blood of a subject.However, there is often a delay between when the insulin is provided andwhen the amount of insulin in the subject's blood plasma reaches maximumconcentration. This amount of time may vary based on the type of insulinand on the physiology of the particular subject. In addition, when thereis an unexpected change in medicament dose has been determined, the useror subject may not be aware of such a case if not looking at the AMD.

In some cases, a subject may receive a manual bolus of insulin ormedicament. For example, a user (e.g., healthcare provider, parent, orguardian) or subject may inject a dose of insulin into the subject. Asanother example, the user or subject may manually direct the automatedblood glucose control system to provide a bolus of insulin to thesubject.

Accordingly, in some embodiments, the motion activated AMD can make aquick change in medicament delivery. For instance, the process 6700enables therapy changes efficiently and promptly by a specified gesturemotion allowing communication between the user and the AMD. By this, itis possible to reduce several steps, e.g., selecting a menu option onthe touchscreen and selecting a submenu option, etc. That is, theone-time motion or touch input can enable to perform various functionsof the AMD (e.g., delivery of medicament, change of medicament dose,acknowledging the alarm, etc.). In addition, the user can be informedwith a medicament dose change based on real time measurement and makesuch a change by a simple motion or touch.

In some cases, the indication of an amount of a manual bolus may bereceived by a user entering a numerical value (e.g., an amount ofinsulin, a number of carbohydrates, or another calculation) associatedwith administering insulin, which may be considered a specified gestureinteraction required for entry of the manual bolus of medicament. Insome cases, a specified gesture interaction required for entry of themanual bolus of medicament may be a sliding action or other movement ona touchscreen to confirm or initiate desired functions as discussedherein. As described above, the automated blood glucose control systemmay automatically-calculate a meal dose of insulin and present it to auser via a user interface where a user may enter the manual bolusinformation.

As described herein, the announcement can be made by generating a soundor vibration without the user having to manipulate the AMD to find out.The user can initiate the medicament delivery by a touch input andaccept any modification in the medicament dose by a touch input as well.The touch input is not limited such that the user can make a single tap,double taps, or triple taps on the touch screen or on any portion of theAMD. For example, one touch may indicate initiating the medicamentdelivery, double tap may indicate confirmation of the delivery, andtriple tap may indicate verification of change in medicament dosedetermined based on detected blood sugar level. Thus, the motion-enabledmedicament delivery efficiently and quickly change the medicamentdelivery to the user in a simplified way.

Example Embodiments

Further embodiments of glucose level control systems that can becombined with the features disclosed herein can be found in: U.S. Pat.App. No. 63/169,112 filed on Mar. 31, 2021; PCT. Pub. No. WO 2021/067856filed on Oct. 2, 2020; U.S. Pat. Pub. No. 2021/0213200 filed on Mar. 25,2021; and PCT Pub. No. WO 2021/067767 filed on Oct. 2, 2020, which areall hereby incorporated by reference in their entireties herein for allpurposes.

Some additional nonlimiting examples of embodiments discussed above areprovided below. These should not be read as limiting the breadth of thedisclosure in any way.

In a 1st example, an ambulatory medicament pump configured to maintaindelivery of therapy to a subject after determining that a possibleocclusion exists in a medicament delivery system, the ambulatorymedicament pump comprising: a medicament reservoir configured to storemedicament to be delivered as therapy to the subject; a medicamentdelivery interface configured to couple to a medicament passagewayconnecting the medicament reservoir to a subcutaneous depot of thesubject through the skin of the subject when the ambulatory medicamentpump is operatively connected to the subject; a pump motor configured todeliver the medicament from the medicament reservoir through themedicament delivery interface; a non-transitory memory configured tostore specific computer-executable instructions; and a hardwareprocessor in communication with the non-transitory memory and configuredto execute the specific computer-executable instructions to at least:detect a fluid delivery parameter associated with the medicamentdelivery system; determine that the fluid delivery parameter satisfiesan initial occlusion condition, wherein the initial occlusion conditionindicates that a possible occlusion exists that interferes with deliveryvia the medicament delivery system; in response to the determinationthat the fluid delivery parameter satisfies the initial occlusioncondition, maintain delivery of therapy to the subject; receive averification parameter associated with the possible occlusion; determinethat the verification parameter satisfies a final occlusion condition,wherein the final occlusion condition indicates that a probableocclusion exists in the medicament delivery system; and in response tothe determination that the verification parameter satisfies the finalocclusion condition, modify delivery of therapy to the subject.

In a 2nd example, the ambulatory medicament pump of example 1, whereinthe hardware processor is further configured to execute the specificcomputer-executable instructions to at least: generate a user alertbased at least in part on the determination that the fluid deliveryparameter satisfies the initial occlusion condition.

In a 3rd example, the ambulatory medicament pump of any of examples 1-2,wherein the hardware processor is further configured to execute thespecific computer-executable instructions to at least: generate a useralert based at least in part on the determination that the verificationparameter satisfies the final occlusion condition.

In a 4th example, the ambulatory medicament pump of any of examples 1-3,wherein the medicament passageway comprises a delivery tube operativelycoupled between the medicament reservoir and an infusion site configuredto deliver the medicament through the skin of the subject.

In a 5th example, the ambulatory medicament pump of any of examples 1-4,wherein the fluid delivery parameter comprises a current supplied to thepump motor.

In a 6th example, the ambulatory medicament pump of any of examples 1-5,wherein modifying delivery of therapy to the subject comprises stoppingdelivery of therapy.

In a 7th example, the ambulatory medicament pump of any of examples 1-6,wherein the verification parameter comprises a glucose level signalreceived from a sensor configured to detect a glucose level of thesubject.

In an 8th example, the ambulatory medicament pump of example 7, whereinthe final occlusion condition comprises a glucose level indicating athreshold value of at least 150 mg/dL of blood glucose concentration.

In a 9th example, the ambulatory medicament pump of any of examples 1-8,wherein the hardware processor is further configured to execute thespecific computer-executable instructions to at least: in response tothe determination that the fluid delivery parameter satisfies theinitial occlusion condition, pause delivery of therapy for at least 3seconds.

In a 10th example, the ambulatory medicament pump of any of examples1-9, wherein the hardware processor is further configured to execute thespecific computer-executable instructions to at least: in response tothe determination that the verification parameter satisfies the finalocclusion condition, increase delivery of therapy to the subject after apassage of an amount of time.

In a 11th example, the ambulatory medicament pump of any of examples1-10, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: in responseto the determination that the fluid delivery parameter satisfies theinitial occlusion condition, modify an attribute of the delivery oftherapy while maintaining delivery of the therapy to the subject.

In a 12th example, the ambulatory medicament pump of any of examples1-11, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: determinethat the fluid delivery parameter satisfies an intermediate occlusioncondition, wherein the intermediate occlusion condition indicates thatthe possible occlusion persists; and in response to the determinationthat the fluid delivery parameter satisfies the intermediate occlusioncondition, modify an attribute of the delivery of therapy.

In a 13th example, the ambulatory medicament pump of any of examples1-12, wherein attribute of the delivery of therapy comprises one or moreof a rate of delivery or a size of a bolus of therapy.

In a 14th example, an occlusion detection system comprising: anon-transitory memory configured to store specific computer-executableinstructions; and a hardware processor in communication with thenon-transitory memory and configured to execute the specificcomputer-executable instructions to at least: receive a fluid deliveryparameter associated with a medicament delivery system; determine thatthe fluid delivery parameter satisfies an initial occlusion condition,wherein the initial occlusion condition indicates that a possibleocclusion exists in the medicament delivery system; in response to thedetermination that the fluid delivery parameter satisfies the initialocclusion condition, send an instruction to the medicament deliverysystem to maintain delivery of therapy to a subject; receive averification parameter associated with the possible occlusion; determinethat the verification parameter satisfies a final occlusion condition,wherein the final occlusion condition indicates that a probableocclusion exists in the medicament delivery system; and in response tothe determination that the verification parameter satisfies the finalocclusion condition, send an instruction to the medicament deliverysystem to modify delivery of therapy to the subject.

In a 15th example, the occlusion detection system of example 14, whereinthe hardware processor is further configured to execute the specificcomputer-executable instructions to at least: generate a user alertbased at least in part on the determination that the fluid deliveryparameter satisfies the initial occlusion condition.

In a 16th example, the occlusion detection system of any of examples14-15, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: generate auser alert based at least in part on the determination that theverification parameter satisfies the final occlusion condition.

In a 17th example, the occlusion detection system of any of examples14-16, wherein the fluid delivery parameter comprises a current suppliedto a pump motor in communication with the occlusion detection system.

In a 18th example, the occlusion detection system of any of examples14-17, wherein the fluid delivery parameter comprises a pressureobtained by a pressure sensor in communication with the occlusiondetection system.

In a 19th example, the occlusion detection system of any of examples14-18, wherein sending an instruction to the medicament delivery systemto modify delivery of therapy to the subject comprises sending aninstruction to the medicament delivery system to halt delivery oftherapy.

In a 20th example, the occlusion detection system of any of examples14-19, wherein the verification parameter comprises a glucose levelsignal received from a sensor configured to detect a glucose level ofthe subject.

In a 21st example, the occlusion detection system of example 20, whereinthe final occlusion condition comprises a glucose level indicating athreshold value of at least 150 mg/dL of blood glucose concentration.

In a 22nd example, the occlusion detection system of any of examples14-21, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: in responseto the determination that the fluid delivery parameter satisfies theinitial occlusion condition, send an instruction to pause delivery oftherapy for at least 3 seconds.

In a 23rd example, the occlusion detection system of any of examples14-22, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: in responseto the determination that the verification parameter satisfies the finalocclusion condition, send an instruction to increase delivery of therapyto the subject after a passage of an amount of time.

In a 24th example, an ambulatory medicament device configured tomaintain indications of alarm conditions on a list of pending alarmconditions without auditory or haptic annunciation of at least some ofthe alarm conditions while a do not disturb mode is active, theambulatory medicament device comprising: a monitoring system interfaceconfigured to receive status information, wherein the status informationcomprises at least one of device information pertaining to a conditionof the ambulatory medicament device or subject information pertaining toa condition of a subject; a memory configured to store specificcomputer-executable instructions and the list of pending alarmconditions; and a hardware processor in communication with the memoryand configured to execute the specific computer-executable instructionsto at least: receive alarm muting instructions via user interaction withan alarm muting control interface; in response to determining that alarmannunciation should be muted in accordance with the alarm mutinginstructions, activate the do not disturb mode of the ambulatorymedicament device, wherein at least some alarm annunciation patterns arenot aurally or haptically annunciated while the ambulatory medicamentdevice is in the do not disturb mode; detect, via the monitoring systeminterface, that the status information or the subject informationindicates at least one of a first alarm condition, a second alarmcondition, or a third alarm condition; determine that the first alarmcondition requires urgent user attention; in response to determiningthat the first alarm condition requires urgent user attention,annunciate the first alarm condition, without deactivating the do notdisturb mode, using a first alarm condition annunciation patterncomprising at least one of auditory or haptic annunciation; maintain anindication of the first alarm condition on the list of pending alarmconditions until the first alarm condition is resolved; determine thatthe second alarm condition does not require urgent user attention; inresponse to determining that the second alarm condition does not requireurgent user attention, maintain an indication of the second alarmcondition on the list of pending alarm conditions until the second alarmcondition is resolved without auditory or haptic annunciation of thesecond alarm condition while the do not disturb mode is active;determine that the third alarm condition does not require urgent userattention and that the third alarm condition has lower priority than thesecond alarm condition; and upon deactivation of the do not disturbmode, annunciate the second alarm condition without auditory or hapticannunciation of the third alarm condition.

In a 25th example, the ambulatory medicament device of example 24,wherein the hardware processor is configured to execute furthercomputer-executable instructions to, in response to determining that thefirst alarm condition requires urgent user attention, deactivate the donot disturb mode.

In a 26th example, the ambulatory medicament device of any of examples24-25, wherein determining that the first alarm condition requiresurgent user attention comprises: determining a severity level of thefirst alarm condition; and determining that the severity level of thefirst alarm condition exceeds a threshold severity level.

In a 27th example, the ambulatory medicament device of any of examples24-26, wherein the alarm muting control interface comprises atouchscreen controller configured to output display signals configuredto generate user interface screens on a touchscreen and to receive userinput signals corresponding to user interaction with the touchscreen.

In a 28th example, the ambulatory medicament device of any of examples24-27, wherein the alarm muting instructions comprise a recurring timeinterval, wherein the hardware processor is configured to executefurther computer-executable instructions to activate the do not disturbmode during the recurring time interval.

In a 29th example, the ambulatory medicament device of example 28,wherein the recurring time interval comprises a time interval occurringevery day between 18:00 and 07:00.

In a 30th example, the ambulatory medicament device of any of examples24-29, wherein the alarm muting control interface is part of a remotedevice that is separate from the ambulatory medicament device.

In a 31st example, the ambulatory medicament device of any of examples24-30, wherein the list of pending alarm conditions is sorted accordingto severity levels of alarm conditions included on the list of pendingalarm conditions.

In a 32nd example, the ambulatory medicament device of any of examples24-31, wherein the list of pending alarm conditions is displayed on auser interface of the ambulatory medicament device.

In a 33rd example, the ambulatory medicament device of example 32,wherein the list of pending alarm conditions comprises alarm statusindicators, wherein the alarm status indicators indicate whether pendingalarm conditions in the list of pending alarm conditions wereannunciated or muted.

In a 34th example, the ambulatory medicament device of any of examples24-33, wherein the alarm muting instructions comprise a time periodduring which the do not disturb mode is to remain active, wherein thehardware processor is configured to execute further computer-executableinstructions to deactivate the do not disturb mode after the time periodhas passed.

In a 35th example, the ambulatory medicament device of example 34,wherein the hardware processor is configured to execute furthercomputer-executable instructions to: receive via user interaction withthe alarm muting control interface, prior to termination of the timeperiod, instructions to deactivate the do not disturb mode; anddeactivate the do not disturb mode.

In a 36th example, the ambulatory medicament device of any of examples24-35, wherein the hardware processor is configured to execute furthercomputer-executable instructions to: determine the second alarmcondition has not been resolved for a threshold amount of time; escalatethe second alarm condition such that the second alarm condition requiresurgent user attention; and in response to determining that the secondalarm condition requires urgent user attention, annunciate the secondalarm condition using a second alarm condition annunciation patterncomprising at least one of auditory or haptic annunciation.

In a 37th example, the ambulatory medicament device of any of examples24-36 wherein resolving alarm conditions comprises at least one of:correcting the alarm conditions, acknowledging the alarm conditions, orsnoozing the alarm conditions.

In a 38th example, the ambulatory medicament device of example 37,wherein correcting the alarm conditions comprises one or more actionstaken by a user that address a condition which caused an alarm to begenerated.

In a 39th example, the ambulatory medicament device of any of examples24-38, wherein the first alarm condition is resolved automatically whenthe status information or the subject information no longer indicatesthe first alarm condition.

In a 40th example, the ambulatory medicament device of any of examples24-39, wherein the hardware processor is configured to execute furthercomputer-executable instructions to maintain an indication of the thirdalarm condition on the list of pending alarm conditions until the thirdalarm condition is resolved without auditory or haptic annunciation ofthe third alarm condition.

In a 41st example, a glucose control system comprising: a monitoringsystem interface configured to receive status information, wherein thestatus information comprises at least one of device informationpertaining to a condition of the glucose control system or subjectinformation pertaining to a condition of a subject; a memory configuredto store specific computer-executable instructions and a list of pendingalarm conditions; and a hardware processor in communication with thememory and configured to execute the specific computer-executableinstructions to at least: receive alarm muting instructions via userinteraction with an alarm muting control interface; in response todetermining that alarm annunciation should be muted in accordance withthe alarm muting instructions, activate a do not disturb mode of theglucose control system, wherein at least some alarm annunciationpatterns are muted while the glucose control system is in the do notdisturb mode; detect, via the monitoring system interface, that thestatus information or the subject information indicates an alarmcondition; determine that the alarm condition does not require urgentuser attention; and in response to determining that the alarm conditiondoes not require urgent user attention, maintain an indication of thealarm condition on the list of pending alarm conditions until the alarmcondition is resolved without auditory or haptic annunciation of thealarm condition while the do not disturb mode is active.

In a 42nd example, the glucose control system of example 41, wherein thelist of pending alarm conditions is sorted according to severity levelsof alarm conditions included on the list of pending alarm conditions.

In a 43rd example, the glucose control system of example 42, wherein thehardware processor is configured to execute further computer-executableinstructions to, upon deactivation of the do not disturb mode,annunciate a most severe alarm condition, based on the severity levelsof the alarm conditions included on the list of pending alarmconditions.

In a 44th example, the glucose control system of any of examples 41-43,wherein the hardware processor is configured to execute furthercomputer-executable instructions to: detect, via the monitoring systeminterface, a second alarm condition; determine that the second alarmcondition requires urgent user attention; and in response to determiningthat the second alarm condition requires urgent user attention,deactivate the do not disturb mode.

In a 45th example, the glucose control system of any of examples 41-44,wherein the hardware processor is configured to execute furthercomputer-executable instructions to: detect, via the monitoring systeminterface, a second alarm condition; determine that the second alarmcondition requires urgent user attention; and in response to determiningthat the second alarm condition requires urgent user attention,annunciate the second alarm condition without deactivating the do notdisturb mode, using a second alarm condition annunciation patterncomprising at least one of auditory or haptic annunciation.

In a 46th example, the glucose control system of any of examples 41-45,wherein the list of pending alarm conditions comprises alarm statusindicators, wherein the alarm status indicators indicate whether pendingalarm conditions in the list of pending alarm conditions wereannunciated or muted.

In a 47th example, the glucose control system of any of examples 41-46,wherein the alarm muting control interface comprises a touchscreencontroller configured to output display signals configured to generateuser interface screens on a touchscreen and to receive user inputsignals corresponding to user interaction with the touchscreen.

In a 48th example, a method of annunciating alarms associated with aglucose control system, the method comprising: receiving alarm mutinginstructions via user interaction with an alarm muting controlinterface; in response to determining that alarm annunciation should bemuted in accordance with the alarm muting instructions, activating a donot disturb mode of the glucose control system, wherein at least somealarm annunciation patterns are muted while the glucose control systemis in the do not disturb mode; detecting that an alarm condition exists;determining that the alarm condition does not require urgent userattention; and in response to determining that the alarm condition doesnot require urgent user attention, maintain an indication of the alarmcondition on a list of pending alarm conditions until the alarmcondition is resolved without auditory or haptic annunciation of thealarm condition while the do not disturb mode is active.

In a 49th example, the method of example 48, wherein detecting that analarm condition exists comprises detecting that at least one of deviceinformation pertaining to a condition of the glucose control system orsubject information pertaining to a condition of a subject indicates analarm condition.

In a 50th example, the method of any of examples 48-49, whereinreceiving the alarm muting instructions comprises receiving, via userinteraction with the alarm muting control interface, a time periodduring which the do not disturb mode is to remain active.

In a 51st example, the method of example 50, further comprising:receiving, via user interaction with the alarm muting control interface,prior to termination of the time period, instructions to deactivate thedo not disturb mode; and deactivating the do not disturb mode.

In a 52nd example, the method of any of examples 48-51, furthercomprising: detecting a second alarm condition; determining that thesecond alarm condition requires urgent user attention; and in responseto determining that the second alarm condition requires urgent userattention, deactivating the do not disturb mode.

In a 53rd example, the method of any of examples 48-52, furthercomprising: detecting a second alarm condition; determining that thesecond alarm condition requires urgent user attention; and in responseto determining that the second alarm condition requires urgent userattention, annunciating the second alarm condition without deactivatingthe do not disturb mode, using a second alarm condition annunciationpattern comprising at least one of auditory or haptic annunciation.

In a 54th example, an ambulatory medicament device configured to displaycritical status information in a power saving mode, the ambulatorymedicament device comprising: a monitoring system interface configuredto receive status information, wherein the status information comprisesat least one of device information pertaining to a condition of theambulatory medicament device or subject information pertaining to acondition of a subject; a touchscreen controller configured to outputdisplay signals configured to generate user interface screens on atouchscreen and to receive user input signals corresponding to userinput on the touchscreen, wherein the touchscreen is configured to beilluminated by a backlight; an accelerometer configured to detect userinteraction with the ambulatory medicament device and output userinteraction signals corresponding to the user interaction with theambulatory medicament device, wherein user interaction with theambulatory medicament device comprises a single tap or a double tap onthe ambulatory medicament device; a memory configured to storecomputer-executable instructions; and a hardware processor incommunication with the memory and configured to execute thecomputer-executable instructions to at least: receive the user inputsignals via the touchscreen controller; receive the user interactionsignals via the accelerometer; activate a power saving mode of theambulatory medicament device after a period of inactivity or in responseto a request to activate the power saving mode, wherein the period ofinactivity comprises the hardware processor not receiving a user inputsignal or a user interaction signal for a predetermined period of time,wherein the touchscreen controller is configured to not receive the userinput signals when the ambulatory medicament device is in the powersaving mode; turn off the backlight; receive the status information viathe monitoring system interface; determine critical status informationfrom the status information; generate a display of a critical statusinformation interface screen on the touchscreen; and display on thecritical status information interface screen at least one criticalstatus indicator selected from a plurality of critical status indicatorscorresponding to the critical status information, wherein the pluralityof critical status indicators comprises: a glucose level indicator ofthe subject, a battery level indicator of the ambulatory medicamentdevice, a therapy status indicator, a remaining medicament levelindicator, and an alarm status indicator.

In a 55th example, the ambulatory medicament device of example 54,wherein the hardware processor is configured to execute furthercomputer-executable instructions to determine that a power level of abattery of the ambulatory medicament device is below a predeterminedpower level threshold and in response to determining that the powerlevel of the battery of the ambulatory medicament device is below thepredetermined power level threshold, the hardware processor isconfigured to execute further computer-executable instructions to:generate a display of a battery status interface; and display on thebattery status interface a battery charging indicator to prioritizedisplaying the status information corresponding to the power level beingbelow the predetermined power level threshold.

In a 56th example, the ambulatory medicament device of example 55,wherein the battery charging indicator comprises an image of a batterycharger for a battery of the ambulatory medicament device.

In a 57th example, the ambulatory medicament device of any of examples54-56, wherein the hardware processor is configured to execute furthercomputer-executable instructions to determine whether a glucose level ofthe subject is within a predetermined glucose range and in response todetermining that the glucose level is not within the predeterminedglucose range, the hardware processor is configured to execute furthercomputer-executable instructions to: generate a display of a glucoseinterface screen; and display on the glucose interface screen theglucose level indicator to prioritize displaying the status informationcorresponding to the glucose level not being within the predeterminedglucose range.

In a 58th example, the ambulatory medicament device of any of examples54-57, wherein the hardware processor is further configured to executethe computer-executable instructions to display on the critical statusinformation interface screen an alarm state icon comprising a visualindication of a count of alarm conditions.

In a 59th example, the ambulatory medicament device of any of examples54-58, wherein the hardware processor is configured to execute furthercomputer-executable instructions to: activate a privacy mode in responseto a request to activate the privacy mode; generate a display of aprivacy mode interface screen; and display on the privacy mode interfacescreen one or more status indicators corresponding to the statusinformation without displaying at least one of the plurality of criticalstatus indicators.

In a 60th example, the ambulatory medicament device of example 59,wherein the at least one of the plurality of critical status indicatorsnot displayed comprises at least one of the glucose level indicator ofthe subject or the therapy status indicator.

In a 61st example, the ambulatory medicament device of example 60,wherein none of the plurality of critical status indicators aredisplayed on the privacy mode interface screen.

In a 62nd example, the ambulatory medicament device of any of examples59-61, wherein the hardware processor is configured to execute furthercomputer-executable instructions to turn off the touchscreen while inthe privacy mode.

In a 63rd example, the ambulatory medicament device of any of examples59-62, wherein the hardware processor is configured to execute furthercomputer-executable instructions to activate the privacy mode whileactivating the power saving mode.

In a 64th example, the ambulatory medicament device of any of examples59-63, wherein the hardware processor is configured to execute furthercomputer-executable instructions to receive the request to activate theprivacy mode interface screen while in the power saving mode.

In a 65th example, the ambulatory medicament device of any of examples59-64, wherein the hardware processor is configured to execute furthercomputer-executable instructions to receive the request to activate theprivacy mode interface screen while not in the power saving mode.

In a 66th example, the ambulatory medicament device of any of examples59-65, wherein the touchscreen comprises a filter configured to have apredetermined viewing angle range relative to the touchscreen such thatinformation cannot be seen on the touchscreen when viewed from an angleoutside of the predetermined viewing angle range.

In a 67th example, the ambulatory medicament device of any of examples59-66, wherein in the power saving mode, the ambulatory medicamentdevice displays the critical status information interface screen byusing 5-10% additional electric current relative to electric currentused with the touchscreen turned off while the ambulatory medicamentdevice is operating.

In a 68th example, the ambulatory medicament device of any of examples54-67, wherein the hardware processor is configured to execute furthercomputer-executable instructions to: determine that the user interactionsignals correspond to a single tap on the ambulatory medicament device;and in response to determining that the user interaction corresponds tothe single tap on the ambulatory medicament device, turn off atouchscreen display.

In a 69th example, the ambulatory medicament device of example 68,wherein the hardware processor is configured to execute furthercomputer-executable instructions to: determine that the user interactionsignals correspond to an other single tap on the ambulatory medicamentdevice; and in response to determining that the user interactioncorresponds to the other single tap on the ambulatory medicament device,turn on the touchscreen while remaining in the power saving mode.

In a 70th example, the ambulatory medicament device of any of examples54-69, wherein the hardware processor is configured to execute furthercomputer-executable instructions to: determine that the user interactionsignals correspond to a double tap on the ambulatory medicament device;and in response to determining that the user interaction corresponds tothe double tap on the ambulatory medicament device, turn on thebacklight while remaining in the power saving mode.

In a 71st example, the ambulatory medicament device of example 70,wherein the hardware processor is configured to execute furthercomputer-executable instructions to: determine that the user interactionsignals correspond to an other double tap on the ambulatory medicamentdevice; and in response to determining that the user interactioncorresponds to the other double tap on the ambulatory medicament device,turn off the backlight while remaining in the power saving mode.

In a 72nd example, the ambulatory medicament device of any of examples54-71, wherein the hardware processor is configured to execute furthercomputer-executable instructions to: determine that the user interactionsignals correspond to a single tap or a double tap on the ambulatorymedicament device; and in response to determining that the userinteraction corresponds to the single tap or the double tap on theambulatory medicament device, deactivate the power saving mode.

In a 73rd example, the ambulatory medicament device of any of examples54-72, wherein the hardware processor is configured to execute furthercomputer-executable instructions to update the critical statusinformation interface screen in the power saving mode less frequentlythan updating the user interface screens in a wake mode of theambulatory medicament device.

In a 74th example, the ambulatory medicament device of any of examples54-73, wherein the hardware processor is configured to execute furthercomputer-executable instructions to: receive a request to activate awake mode of the ambulatory medicament device; and in response toreceiving the request to activate the wake mode, deactivate the powersaving mode.

In a 75th example, the ambulatory medicament device of example 74,wherein in response to receiving the request to activate the wake mode,the hardware processor is configured to execute furthercomputer-executable instructions to: determine that the request toactivate the wake mode was received during a predefined period of time;and in response to determining that the request was received during thepredefined period of time, turn on the backlight.

In a 76th example, the ambulatory medicament device of example 75,wherein the predefined period of time is between 8:00 PM and 7:00 AM ofa day.

In a 77th example, the ambulatory medicament device of any of examples74-76, wherein the hardware processor is configured to execute furthercomputer-executable instructions to receive a wake request signalcorresponding to user request on a wake interface of the ambulatorymedicament device to active the wake mode.

In a 78th example, the ambulatory medicament device of example 77,wherein the wake interface comprises a physical button, a capacitivesensor, or an inductive sensor.

In a 79th example, the ambulatory medicament device of any of examples77-78, wherein the hardware processor is configured to execute furthercomputer-executable instructions to: generate a display of a powersaving interface screen on the touchscreen; and display on the powersaving interface screen one or more wake mode indicators correspondingto a location of the wake interface, a message to interact with the wakeinterface to activate the wake mode, or both.

In an 80th example, the ambulatory medicament device of example 79,wherein the hardware processor is configured to execute furthercomputer-executable instructions to not display the one or more wakemode indicators in the wake mode.

In a 81st example, the ambulatory medicament device of any of examples77-80, wherein in response to receiving the wake request signal, thehardware processor is configured to execute further computer-executableinstructions to: determine that the wake request signal was received fora first predetermined time length; and in response to determining thatthe wake request signal was received for the first predetermined timelength, turn on the backlight to 40-60% brightness relative to a maximumbrightness of the backlight.

In a 82nd example, the ambulatory medicament device of example 81,wherein the hardware processor is configured to execute furthercomputer-executable instructions to: determine that the wake requestsignal was received for a second predetermined time length, the secondpredetermined time length being longer than the first predetermined timelength; and in response to determining that the wake request signal wasreceived for the second predetermined time length, turn on the backlightto the maximum brightness of the backlight.

In an 83rd example, the ambulatory medicament device of any of examples54-82, wherein the hardware processor is configured to execute furthercomputer-executable instructions to lower a refresh rate of thetouchscreen to a lower refresh level relative to a maximum refresh rateof touchscreen.

In an 84th example, the ambulatory medicament device of example 83,wherein the lower refresh rate of the touchscreen is 1 hertz.

In an 85th example, the ambulatory medicament device of any of examples83-84, wherein the maximum refresh rate of the touchscreen is 60 hertz.

In an 86th example, the ambulatory medicament device of any of examples54-85, wherein the hardware processor is configured to execute furthercomputer-executable instructions to lower brightness of the touchscreenof the ambulatory medicament device to a lower brightness level relativeto a full brightness level of the touchscreen.

In an 87th example, the ambulatory medicament device of any of examples54-86, wherein the ambulatory medicament device comprises a bi-hormonalpump capable of administering insulin and a counter-regulatory agent.

In an 88th example, the ambulatory medicament device of any of examples54-87, wherein the status information is received from a sensor thatmeasures at least one of a characteristic of the ambulatory medicamentdevice or a physiological parameter of the subject.

In a 89th example, an ambulatory medicament device configured to displaycritical status information in a power saving mode, the ambulatorymedicament device comprising: a monitoring system interface configuredto receive status information, wherein the status information comprisesat least one of device information pertaining to a condition of theambulatory medicament device or subject information pertaining to acondition of a subject; a motion sensor configured to detect userinteraction with the ambulatory medicament device and output userinteraction signals corresponding to the user interaction with theambulatory medicament device, wherein user interaction with theambulatory medicament device comprises a single tap or a double tap onthe ambulatory medicament device; a memory configured to storecomputer-executable instructions; and a hardware processor incommunication with the memory and configured to execute thecomputer-executable instructions to at least: receive the userinteraction signals via the motion sensor; activate a power saving modeof the ambulatory medicament device after a period of inactivity or inresponse to a request to activate the power saving mode, wherein theperiod of inactivity comprises the hardware processor not receiving auser interaction signal for a predetermined period of time; turn off abacklight of the ambulatory medicament device configured to illuminate atouchscreen of the ambulatory medicament device; receive the statusinformation via the monitoring system interface; determine criticalstatus information from the status information; generate a display of acritical status information interface screen on the touchscreen; anddisplay on the critical status information interface screen at least oneof a plurality of critical status indicators corresponding to thecritical status information, wherein the plurality of critical statusindicators comprises: a medicament device status indicator, and asubject status indicator.

In a 90th example, the ambulatory medicament device of example 89,further comprising any one or more features of example 54 to example 88.

In a 91st example, an ambulatory medicament device configured to displaycritical status information in a power saving mode, the ambulatorymedicament device comprising: a monitoring system interface configuredto receive status information, wherein the status information comprisesat least one of device information pertaining to a condition of theambulatory medicament device or subject information pertaining to acondition of a subject; a memory configured to store computer-executableinstructions; and a hardware processor in communication with the memoryand configured to execute the computer-executable instructions to atleast: activate a power saving mode of the ambulatory medicament deviceafter a period of inactivity or in response to a request to activate thepower saving mode, wherein the period of inactivity comprises thehardware processor not receiving user input for a predetermined periodof time; turn off a backlight of the ambulatory medicament deviceconfigured to illuminate a touchscreen of the ambulatory medicamentdevice; receive the status information via the monitoring systeminterface; determine critical status information from the statusinformation; generate a display of a critical status informationinterface screen on the touchscreen; and display on the critical statusinformation interface screen at least one of a plurality of criticalstatus indicators corresponding to the critical status information,wherein the plurality of critical status indicators comprises: amedicament device status indicator, and a subject status indicator.

In a 92nd example, the ambulatory medicament device of example 91,further comprising any one or more features of example 54 to example 88.

In a 93rd example, an ambulatory medicament device configured to displaycritical status information in a power saving mode, the ambulatorymedicament device comprising: a monitoring system interface configuredto receive status information, wherein the status information comprisesat least one of device information pertaining to a condition of theambulatory medicament device or subject information pertaining to acondition of a subject; a memory configured to store computer-executableinstructions; and a hardware processor in communication with the memoryand configured to execute the computer-executable instructions to atleast: activate a power saving mode of the ambulatory medicament deviceafter a period of inactivity or in response to a request to activate thepower saving mode, wherein the period of inactivity comprises thehardware processor not receiving user input for a predetermined periodof time; receive the status information via the monitoring systeminterface; determine critical status information from the statusinformation; generate a display of a critical status informationinterface screen on a touchscreen of the ambulatory medicament device;and display on the critical status information interface screen at leastone of a plurality of critical status indicators corresponding to thecritical status information, wherein the plurality of critical statusindicators comprises: a medicament device status indicator, and asubject status indicator.

In a 94th example, the ambulatory medicament device of example 93,further comprising any one or more features of example 54 to example 88.

In a 95th example, the ambulatory medicament device of any of examples93-94, wherein the hardware processor is configured to execute furthercomputer-executable instructions to dim a backlight of the ambulatorymedicament device to a lower illumination level relative to a maximumillumination level of the backlight, the backlight configured toilluminate the touchscreen.

In a 96th example, the ambulatory medicament device of example 95,wherein the lower illumination level of the backlight is 40-60% of themaximum illumination level of the backlight.

In a 97th example, an ambulatory medicament device configured to respondto user input or interaction in a power saving mode, the ambulatorymedicament device comprising: a monitoring system interface configuredto receive status information, wherein the status information comprisesat least one of device information pertaining to a condition of theambulatory medicament device or subject information pertaining to acondition of a subject; a touchscreen controller configured to outputdisplay signals configured to generate user interface screens on atouchscreen and to receive user input signals corresponding to userinput on the touchscreen, wherein the touchscreen is configured to beilluminated by a backlight; an accelerometer configured to detect userinteraction with the ambulatory medicament device and output userinteraction signals corresponding to the user interaction with theambulatory medicament device, wherein user interaction with theambulatory medicament device comprises a single tap or a double tap onthe ambulatory medicament device; a memory configured to storecomputer-executable instructions; and a hardware processor incommunication with the memory and configured to execute thecomputer-executable instructions to at least: receive the user inputsignals via the touchscreen controller; receive the user interactionsignals via the accelerometer; activate a power saving mode of theambulatory medicament device after a period of inactivity or in responseto a request to activate the power saving mode, wherein the period ofinactivity comprises the hardware processor not receiving a user inputsignal or a user interaction signal for a predetermined period of time;in response to activating the power saving mode, cause the touchscreencontroller to not receive the user input signals; receive the statusinformation via the monitoring system interface; determine that thestatus information satisfies an alarm condition for the ambulatorymedicament device or for the subject; in response to determining thatthe status information satisfies the alarm condition: generate a displayof an alarm interface screen on the touchscreen; display on the alarminterface screen one or more alarm status indicators corresponding tothe alarm condition; determine that the user interaction signalscorrespond to the double tap on the ambulatory medicament device; and inresponse to determining that the user interaction corresponds to thedouble tap on the ambulatory medicament device: snooze the alarmcondition; and update the one or more alarm status indicators toindicate that the alarm condition was snoozed; determine that the statusinformation does not satisfy an alarm condition for the ambulatorymedicament device or for the subject; and in response to determiningthat the status information does not satisfy the alarm condition:determine that the user interaction signals correspond to the single tapon the ambulatory medicament device or the double tap on the ambulatorymedicament device; in response to determining that the user interactioncorresponds to the single tap on the ambulatory medicament device:generate a display of the user interface screens on the touchscreen; anddisplay on the user interface screens one or more status informationindicators corresponding to the status information; and in response todetermining that the user interaction corresponds to the double tap onthe ambulatory medicament device, generate the display of the userinterface screens on the touchscreen; display on the user interfacescreens the one or more status information indicators corresponding tothe status information; and turn on the backlight to illuminate thetouchscreen.

In a 98th example, the ambulatory medicament device of example 97,wherein in response to determining that the status information satisfiesthe alarm condition, the hardware processor is configured to executefurther computer-executable instructions to annunciate the alarmcondition using an alarm annunciation pattern comprising at least one ofaudio or haptic annunciation.

In a 99th example, the ambulatory medicament device of any of examples97-98, wherein in response to determining that the status informationsatisfies the alarm condition, the hardware processor is configured toexecute further computer-executable instructions to: determine that thealarm condition requires urgent user attention; and in response todetermining that the alarm condition requires urgent user attention,display on the alarm interface screen the one or more alarm statusindicators without snoozing the alarm condition in response to thedouble tap on the ambulatory medicament device.

In a 100th example, the ambulatory medicament device of example 99, inresponse to determining that the alarm condition requires urgent userattention, the hardware processor is configured to execute furthercomputer-executable instructions to deactivate the power saving mode.

In a 101st example, the ambulatory medicament device of any of examples99-100, wherein the hardware processor is configured to execute furthercomputer-executable instructions to: determine that the alarm conditiondoes not require urgent user attention; and in response to determiningthat the alarm condition does not require urgent user attention, allowthe alarm condition to be snoozed.

In a 102nd example, the ambulatory medicament device of any of examples97-101, wherein in response to snoozing the alarm condition, thehardware processor is configured to execute further computer-executableinstructions to maintain the one or more alarm status indicators on alist of pending alarm conditions.

In a 103rd example, the ambulatory medicament device of example 102,wherein the list of pending alarm conditions is not displayed on theuser interface screens with the power saving mode active.

In a 104th example, the ambulatory medicament device of any of examples102-103, wherein the list of pending alarm conditions comprises alarmstatus icons, wherein the alarm status icons indicate whether the alarmcondition was snoozed.

In a 105th example, the ambulatory medicament device of any of examples97-104, wherein in response to displaying on the alarm interface screenthat the alarm condition was snoozed, the hardware processor isconfigured to execute further computer-executable instructions to notdisplay the one or more alarm status indicators after the predeterminedperiod of time or an other predetermined period of time.

In a 106th example, the ambulatory medicament device of any of examples97-105, wherein activating the power saving mode comprises turning offthe backlight.

In a 107th example, the ambulatory medicament device of any of examples97-106, wherein activating the power saving mode comprises turning offthe touchscreen.

In 108th example, the ambulatory medicament device of example 107,wherein in response to determining that the status information satisfiesthe alarm condition, the hardware processor is configured to executefurther computer-executable instructions to turn on the touchscreen.

In a 109th example, the ambulatory medicament device of any of examples107-108, wherein in response to determining that the status informationdoes not satisfy the alarm condition and that the user interactionsignals correspond to the single tap or the double tap on the ambulatorymedicament device, the hardware processor is configured to executefurther computer-executable instructions to turn on the touchscreen.

In a 110th example, the ambulatory medicament device of any of examples107-109, wherein in response to determining that the status informationdoes not satisfy the alarm condition and that the user interactionsignals correspond to the double tap on the ambulatory medicamentdevice, the hardware processor is configured to execute furthercomputer-executable instructions to turn on the touchscreen and turn onthe backlight.

In a 111th example, the ambulatory medicament device of any of examples97-110, wherein the hardware processor is configured to execute furthercomputer-executable instructions to: determine that the user interactionsignals correspond to an other single tap on the ambulatory medicamentdevice; and in response to determining that the user interactioncorresponds to the other single tap on the ambulatory medicament device,turn off the touchscreen.

In a 112th example, the ambulatory medicament device of any of examples97-111, wherein the hardware processor is configured to execute furthercomputer-executable instructions to: determine that the user interactionsignals correspond to an other double tap on the ambulatory medicamentdevice; and in response to determining that the user interactioncorresponds to the other double tap on the ambulatory medicament device,turn off the backlight.

In a 113th example, the ambulatory medicament device of any of examples97-112, wherein in response to determining that the status informationsatisfies the alarm condition, the hardware processor is configured toexecute further computer-executable instructions to deactivate the powersaving mode.

In a 114th example, the ambulatory medicament device of example 113,wherein in response to displaying on the alarm interface screen that thealarm condition was snoozed, the hardware processor is configured toexecute further computer-executable instructions to activate the powersaving mode of the ambulatory medicament device after the period ofinactivity.

In a 115th example, the ambulatory medicament device of any of examples97-114, wherein in response to determining that the status informationdoes not satisfy the alarm condition and that the user interactionsignals correspond to the single tap or the double tap on the ambulatorymedicament device, the hardware processor is configured to executefurther computer-executable instructions to deactivate the power savingmode.

In a 116th example, the ambulatory medicament device of example 115,wherein the hardware processor is configured to execute furthercomputer-executable instructions to: determine that the user interactionsignals correspond to an other single tap on the ambulatory medicamentdevice; and in response to determining that the user interactioncorresponds to the other single tap on the ambulatory medicament device,activate the power saving mode of the ambulatory medicament device.

In a 117th example, the ambulatory medicament device of any of examples97-116, wherein in response to determining that the status informationdoes not satisfy the alarm condition and that the user interactioncorresponds to the single tap on the ambulatory medicament device, thehardware processor is configured to execute further computer-executableinstructions to: generate the display of the alarm interface screen; anddisplay on the alarm screen interface that one or more alarm conditionswere previously snoozed.

In a 118th example, the ambulatory medicament device of any of examples97-117, wherein in response to activating the power saving mode, thehardware processor is configured to execute further computer-executableinstructions to: determine critical status information from the statusinformation; generate a display of a critical status informationinterface screen; and display on the critical status informationinterface screen at least one of a plurality of critical statusindicators corresponding to the critical status information.

In a 119th example, the ambulatory medicament device of example 118,wherein in response to activating the power saving mode, the hardwareprocessor is configured to execute further computer-executableinstructions to turn off the backlight.

In a 120th example, the ambulatory medicament device of any of examples118-119, wherein the plurality of critical status indicators comprises aglucose level indicator of the subject, a battery level indicator of theambulatory medicament device, an alert status indicator, a therapystatus indicator, a remaining medicament level indicator, and the one ormore alarm status indicators.

In a 121st example, the ambulatory medicament device of any of examples118-120, wherein the hardware processor is configured to execute furthercomputer-executable instructions to update the critical statusinformation interface screen in the power saving mode less frequentlythan the user interface screens in a wake mode of the ambulatorymedicament device.

In a 122nd example, the ambulatory medicament device of any of examples97-120, wherein the hardware processor is configured to execute furthercomputer-executable instructions to: receive a request to activate awake mode of the ambulatory medicament device; and in response toreceiving the request to activate the wake mode, deactivate the powersaving mode.

In a 123rd example, the ambulatory medicament device of example 122,wherein the request to activate the wake mode comprises the single tapor the double tap.

In a 124th example, the ambulatory medicament device of any of examples122-123, wherein in response to receiving the request to activate thewake mode, the hardware processor is configured to execute furthercomputer-executable instructions to: determine whether the request toactive the wake mode was received during a predefined period of time;and in response to determining that the request was received during thepredefined period of time, turn on the backlight.

In a 125th example, the ambulatory medicament device of example 124,wherein the predefined period of time is between 8:00 PM and 7:00 AM ofa day.

In a 126th example, the ambulatory medicament device of any of examples122-125, wherein the hardware processor is configured to execute furthercomputer-executable instructions to receive a wake request signalcorresponding to user request on a wake interface of the ambulatorymedicament device to active the wake mode.

In a 127th example, the ambulatory medicament device of example 126,wherein the wake interface comprises a comprises a physical button, acapacitive sensor, or an inductive sensor.

In a 128th example, the ambulatory medicament device of any of examples126-127, wherein the request to active the power saving mode is receivedvia the wake interface of the ambulatory medicament device.

In a 129th example, the ambulatory medicament device of any of examples97-128, wherein, in response to updating the one or more alarm statusindicators to indicate that the alarm condition was snoozed, thehardware processor is configured to execute further computer-executableinstructions to display on the alarm interface screen that the alarmcondition was snoozed.

In a 130th example, the ambulatory medicament device of any of examples97-129, wherein in response to determining that the status informationsatisfies the alarm condition, the hardware processor is configured toexecute further computer-executable instructions to annunciate the alarmcondition using at least one of an auditory annunciation pattern or ahaptic annunciation pattern.

In a 131st example, the ambulatory medicament device of any of examples97-130, wherein the ambulatory medicament device comprises a bi-hormonalpump capable of administering insulin and a counter-regulatory agent.

In a 132nd example, the ambulatory medicament device of any of examples97-131, wherein the status information is received from a sensor thatmeasures at least one of a characteristic of the ambulatory medicamentdevice or a physiological parameter of the subject.

In a 133rd example, an ambulatory medicament device configured torespond to user interaction in a power saving mode, the ambulatorymedicament device comprising: a monitoring system interface configuredto receive status information, wherein the status information comprisesat least one of device information pertaining to a condition of theambulatory medicament device or subject information pertaining to acondition of a subject; a motion sensor configured to detect userinteraction with the ambulatory medicament device and output userinteraction signals corresponding to the user interaction with theambulatory medicament device, wherein user interaction with theambulatory medicament device comprises a single tap or a double tap onthe ambulatory medicament device; a memory configured to storecomputer-executable instructions; and a hardware processor incommunication with the memory and configured to execute thecomputer-executable instructions to at least: receive the userinteraction signals via the motion sensor; activate a power saving modeof the ambulatory medicament device after a period of inactivity or inresponse to a request to activate the power saving mode, wherein theperiod of inactivity comprises the hardware processor not receiving auser interaction signal for a predetermined period of time; receive thestatus information via the monitoring system interface; determine thatthe status information satisfies an alarm condition for the ambulatorymedicament device or for the subject; in response to determining thatthe status information satisfies the alarm condition: generate a displayof an alarm interface screen on a touchscreen of the ambulatorymedicament device; display on the alarm interface screen one or morealarm status indicators corresponding to the alarm condition; determinethat the user interaction signals correspond to the double tap on theambulatory medicament device; and in response to determining that theuser interaction corresponds to the double tap on the ambulatorymedicament device, snooze the alarm condition.

In a 134th example, the ambulatory medicament device of example 133,wherein the motion sensor comprises at least one of an accelerometer ora gyroscope.

In a 135th example, the ambulatory medicament device of any of examples133-134, further comprising a touchscreen controller configured tooutput display signals configured to generate user interface screens onthe touchscreen and to receive user input signals corresponding to userinput on the touchscreen, the hardware processor is configured toexecute further computer-executable instructions to receive the userinput signals via the touchscreen controller, wherein the period ofinactivity for activating the power saving mode comprises the hardwareprocessor not receiving a user input signal for the predetermined periodof time.

In a 136th example, the ambulatory medicament device of example 135,wherein the hardware processor is configured to execute furthercomputer-executable instructions to: determine that the user interactionsignals correspond to the single tap on the ambulatory medicament deviceor the double tap on the ambulatory medicament device; in response todetermining that the user interaction corresponds to the single tap onthe ambulatory medicament device: cause the touchscreen controller toreceive the user input signals; and in response to determining that theuser interaction corresponds to the double tap on the ambulatorymedicament device, cause the touchscreen controller to receive the userinput signals; and turn on a backlight of the ambulatory medicamentdevice to illuminate the touchscreen.

In a 137th example, the ambulatory medicament device of any of examples133-136, wherein the hardware processor is configured to execute furthercomputer-executable instructions to display on the alarm interfacescreen that the alarm condition was snoozed.

In a 138th example, the ambulatory medicament device of any of examples133-137, wherein the hardware processor is configured to execute furthercomputer-executable instructions to: determine that the user interactionsignals correspond to the single tap on the ambulatory medicament deviceor the double tap on the ambulatory medicament device; in response todetermining that the user interaction corresponds to the single tap onthe ambulatory medicament device: generate a display of the userinterface screens on the touchscreen of the ambulatory medicamentdevice; and display on the user interface screens one or more statusinformation indicators corresponding to the status information; and inresponse to determining that the user interaction corresponds to thedouble tap on the ambulatory medicament device: generate the display ofthe user interface screens on the touchscreen; display on the userinterface screens the one or more status information indicatorscorresponding to the status information; and turn on a backlight of theambulatory medicament device to illuminate the touchscreen.

In a 139th example, the ambulatory medicament device of any of examples133-138, wherein the hardware processor is configured to execute furthercomputer-executable instructions to: determine that the user interactionsignals correspond to the single tap on the ambulatory medicament deviceor the double tap on the ambulatory medicament device; in response todetermining that the user interaction corresponds to the single tap onthe ambulatory medicament device: turn on a touchscreen of theambulatory medicament device; and in response to determining that theuser interaction corresponds to the double tap on the ambulatorymedicament device: turn on the touchscreen; and turn on a backlight ofthe ambulatory medicament device to illuminate the touchscreen.

In a 140th example, the ambulatory medicament device of any of examples133-139, wherein the touchscreen is configured to be illuminated by abacklight.

In a 141st example, the ambulatory medicament device of any of examples133-140, further comprising any one or more features of example 98 toexample 132.

In a 142nd example, an ambulatory medicament device configured torespond to user interaction, the ambulatory medicament devicecomprising: a monitoring system interface configured to receive statusinformation, wherein the status information comprises at least one ofdevice information pertaining to a condition of the ambulatorymedicament device or subject information pertaining to a condition of asubject; a user interaction sensor configured to detect user interactionwith the ambulatory medicament device and output user interactionsignals corresponding to the user interaction with the ambulatorymedicament device, wherein user interaction with the ambulatorymedicament device comprises a single tap or a double tap on theambulatory medicament device; a memory configured to storecomputer-executable instructions; and a hardware processor incommunication with the memory and configured to execute thecomputer-executable instructions to at least: receive the userinteraction signals via the user interaction sensor; activate a powersaving mode of the ambulatory medicament device after a period ofinactivity or in response to a request to activate the power savingmode, wherein the period of inactivity comprises the hardware processornot receiving a user interaction signal for a predetermined period oftime; receive the status information via the monitoring systeminterface; determine that the status information satisfies an alarmcondition for the ambulatory medicament device or for the subject; inresponse to determining that the status information satisfies the alarmcondition: generate a display of an alarm interface screen on atouchscreen of the ambulatory medicament device; display on the alarminterface screen one or more alarm status indicators corresponding tothe alarm condition; determine that the user interaction signalscorrespond to the double tap on the ambulatory medicament device; and inresponse to determining that the user interaction corresponds to thedouble tap on the ambulatory medicament device, snooze the alarmcondition.

In a 143rd example, the ambulatory medicament device of example 142,wherein the user interaction sensor comprises at least one of a motionsensor or a touchscreen.

In a 144th example, the ambulatory medicament device of any of examples142-143, wherein the hardware processor is configured to execute furthercomputer-executable instructions to activate a power saving mode of theambulatory medicament device after a period of inactivity or in responseto a request to activate the power saving mode, wherein the period ofinactivity comprises the hardware processor not receiving a userinteraction signal for a predetermined period of time.

In a 145th example, the ambulatory medicament device of any of examples142-144, further comprising any one or more features of example 98 toexample 132 and example 134 to example 141.

In a 146th example, an ambulatory medicament device configured torespond to user input or interaction in a power saving mode, theambulatory medicament device comprising: a monitoring system interfaceconfigured to receive status information, wherein the status informationcomprises at least one of device information pertaining to a conditionof the ambulatory medicament device or subject information pertaining toa condition of a subject; a touchscreen controller configured to outputdisplay signals configured to generate user interface screens on atouchscreen and to receive user input signals corresponding to userinput on the touchscreen, wherein the touchscreen is configured to beilluminated by a backlight; a motion sensor configured to detect userinteraction with the ambulatory medicament device and output userinteraction signals corresponding to the user interaction with theambulatory medicament device, wherein user interaction with theambulatory medicament device comprises a single tap or a double tap onthe ambulatory medicament device; a memory configured to storecomputer-executable instructions; and a hardware processor incommunication with the memory and configured to execute thecomputer-executable instructions to at least: receive the userinteraction signals via the motion sensor; activate a power saving modeof the ambulatory medicament device after a period of inactivity or inresponse to a request to activate the power saving mode, wherein theperiod of inactivity comprises the hardware processor not receiving auser interaction signal for a predetermined period of time; in responseto activating the power saving mode, cause the touchscreen controller tonot receive the user input signals; receive the status information viathe monitoring system interface; determine that the status informationsatisfies an alarm condition for the ambulatory medicament device or forthe subject; in response to determining that the status informationsatisfies the alarm condition: cause the touchscreen controller toreceive the user input signals; determine that the user interactionsignals correspond to the double tap on the ambulatory medicamentdevice; and in response to determining that the user interactioncorresponds to the double tap on the ambulatory medicament device,snooze the alarm condition.

In a 147th example, the ambulatory medicament device of example 146,further comprising any one or more features of example 97 to example144.

In a 148th example, an ambulatory medicament device configured torespond to user interaction in a power saving mode, the ambulatorymedicament device comprising: a monitoring system interface configuredto receive status information, wherein the status information comprisesat least one of device information pertaining to a condition of theambulatory medicament device or subject information pertaining to acondition of a subject; a motion sensor configured to detect userinteraction with the ambulatory medicament device and output userinteraction signals corresponding to the user interaction with theambulatory medicament device, wherein user interaction with theambulatory medicament device comprises a single tap or a double tap onthe ambulatory medicament device; a memory configured to storecomputer-executable instructions; and a hardware processor incommunication with the memory and configured to execute thecomputer-executable instructions to at least: receive the userinteraction signals via the motion sensor; activate a power saving modeof the ambulatory medicament device after a period of inactivity or inresponse to a request to activate the power saving mode, wherein theperiod of inactivity comprises the hardware processor not receiving auser interaction signal for a predetermined period of time; receive thestatus information via the monitoring system interface; determine thatthe user interaction signals correspond to the single tap on theambulatory medicament device or the double tap on the ambulatorymedicament device; in response to determining that the user interactioncorresponds to the single tap on the ambulatory medicament device:generate a display of the user interface screens on a touchscreen of theambulatory medicament device; and display on the user interface screensone or more status information indicators corresponding to the statusinformation; and in response to determining that the user interactioncorresponds to the double tap on the ambulatory medicament device,generate the display of the user interface screens on the touchscreen;display on the user interface screens the one or more status informationindicators corresponding to the status information; and turn on abacklight of the ambulatory medicament device to illuminate thetouchscreen.

In a 149th example, the ambulatory medicament device of example 148,further comprising any one or more features of example 97 to example144.

In a 150th example, in ambulatory medicament device configured torespond to user interaction in a power saving mode, the ambulatorymedicament device comprising: a user interaction sensor configured todetect user interaction with the ambulatory medicament device and outputuser interaction signals corresponding to the user interaction with theambulatory medicament device, wherein user interaction with theambulatory medicament device comprises a single tap or a double tap onthe ambulatory medicament device; a memory configured to storecomputer-executable instructions; and a hardware processor incommunication with the memory and configured to execute thecomputer-executable instructions to at least: receive the userinteraction signals via the user interaction sensor; activate a powersaving mode of the ambulatory medicament device after a period ofinactivity or in response to a request to activate the power savingmode, wherein the period of inactivity comprises the hardware processornot receiving a user interaction signal for a predetermined period oftime; determine that the user interaction signals correspond to thesingle tap on the ambulatory medicament device or the double tap on theambulatory medicament device; in response to determining that the userinteraction corresponds to the single tap on the ambulatory medicamentdevice: turn on a touchscreen of the ambulatory medicament device; andin response to determining that the user interaction corresponds to thedouble tap on the ambulatory medicament device, turn on the touchscreen;and turn on a backlight of the ambulatory medicament device toilluminate the touchscreen.

In a 151st example, the ambulatory medicament device of example 150,further comprising any one or more features of example 97 to example144.

In a 152nd example, an ambulatory medicament device configured torespond to user input or interaction in a power saving mode, theambulatory medicament device comprising: a touchscreen controllerconfigured to output display signals configured to generate userinterface screens on a touchscreen and to receive user input signalscorresponding to user input on the touchscreen, wherein the touchscreenis configured to be illuminated by a backlight; a motion sensorconfigured to detect user interaction with the ambulatory medicamentdevice and output user interaction signals corresponding to the userinteraction with the ambulatory medicament device, wherein userinteraction with the ambulatory medicament device comprises a single tapor a double tap on the ambulatory medicament device; a memory configuredto store computer-executable instructions; and a hardware processor incommunication with the memory and configured to execute thecomputer-executable instructions to at least: receive the user inputsignals via the touchscreen controller; receive the user interactionsignals via the motion sensor; activate a power saving mode of theambulatory medicament device after a period of inactivity or in responseto a request to activate the power saving mode, wherein the period ofinactivity comprises the hardware processor not receiving a user inputsignal for a predetermined period of time; in response to activating thepower saving mode, cause the touchscreen controller to not receive theuser input signals; determine that the user interaction signalscorrespond to the single tap on the ambulatory medicament device or thedouble tap on the ambulatory medicament device; in response todetermining that the user interaction corresponds to the single tap onthe ambulatory medicament device: cause the touchscreen controller toreceive the user input signals; and in response to determining that theuser interaction corresponds to the double tap on the ambulatorymedicament device, cause the touchscreen controller to receive the userinput signals; and turn on the backlight to illuminate the touchscreen.

In a 153rd example, the ambulatory medicament device of example 152,further comprising any one or more features of example 97 to example144.

In a 154th example, an ambulatory medicament device configured to managea medicament therapy regimen based on motion data associated withmovement of the ambulatory medicament device, the ambulatory medicamentdevice comprising: a medicament reservoir configured to store amedicament; an ambulatory medicament pump configured to deliver themedicament from the medicament reservoir to a subject; a motion sensorconfigured to collect the motion data; a memory configured to storespecific computer-executable instructions; and a hardware processor incommunication with the memory and configured to execute the specificcomputer-executable instructions to at least: receive the motion datafrom the motion sensor; detect a freefall motion of the ambulatorymedicament device based on the motion data; and in response to detectingthe freefall motion, halt operation of the ambulatory medicament pump.

In a 155th example, the ambulatory medicament device of example 154,wherein the halt operation of the ambulatory medicament pump comprisespausing delivery of the medicament, wherein the hardware processor isfurther configured to execute the specific computer-executableinstructions to at least: pause the delivery of the medicament byceasing rotation of a motor of the ambulatory medicament pump.

In a 156th example, the ambulatory medicament device of any of examples154-155, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: pause thedelivery of the medicament by cutting power supply to the ambulatorymedicament pump.

In a 157th example, the ambulatory medicament device of any of examples154-156, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: record anamount of medicament administered to the subject; and in response todetecting the freefall motion: determine an amount of medicamentadministered between a time the freefall motion was detected and a timedelivery of the medicament was paused, and record the amount ofmedicament administered between the time the freefall motion wasdetected and the time delivery of the medicament was paused.

In a 158th example, the ambulatory medicament device of example 157,wherein the hardware processor is configured to execute the specificcomputer-executable instructions to at least: determine the amount ofmedicament administered to the subject based on a number of cyclescompleted by the ambulatory medicament pump between the time thefreefall motion was detected and the time delivery of the medicament waspaused.

In a 159th example, the ambulatory medicament device of any of examples154-158, wherein the ambulatory medicament pump is a peristaltic pump.

In a 160th example, the ambulatory medicament device of any of examples154-159, wherein the hardware processor is further configured to executethe computer-specific executable instructions to at least: detect an endof the freefall motion.

In a 161st example, the ambulatory medicament device of example 160,wherein the hardware processor is further configured to execute thecomputer-executable instructions to at least: in response to detectingthe end of the freefall motion, resume administering the medicament tothe subject.

In a 162nd example, the ambulatory medicament device of example 161,wherein the hardware processor is further configured to execute thecomputer-executable instructions to at least: in response to detectingthe end of the freefall motion, notify the subject of the resumption ofadministering the medicament to the subject.

In a 163rd example, the ambulatory medicament device of example 162,wherein the resumption of administering the medicament to the subject isnotified via a user interface of the ambulatory medicament device.

In a 164th example, the ambulatory medicament device of any of examples162-163, wherein the hardware processor is further configured to executethe computer-executable instructions to at least: in response todetecting the end of the freefall motion, request the subject to acceptthe resumption of administering the medicament to the subject via a userinterface.

In a 165th example, the ambulatory medicament device of example 164,wherein the hardware processor is further configured to execute thecomputer-executable instructions to at least: in response to receiving auser's input, resume administering the medicament to the subject.

In a 166th example, the ambulatory medicament device of any of examples160-165, wherein the hardware processor is further configured to executethe computer-executable instructions to at least: in response todetecting the end of the freefall motion, retrieve the motion data fromthe motion sensor, wherein the motion data includes an acceleration ofthe ambulatory medicament device; calculate a jerk of the ambulatorymedicament device during or following the freefall motion based on theacceleration; determine whether the jerk exceeds a threshold value; andin response to determining that the jerk is less than the thresholdvalue, resume administering the medicament to the subject.

In a 167th example, the ambulatory medicament device of example 166,wherein the hardware processor is further configured to execute thespecific computer-executable instructions to at least: in response todetermining that the jerk exceeds the threshold value, generate analarm; and receive an alarm response signal from the subject.

In a 168th example, the ambulatory medicament device of example 167,wherein the alarm comprises an urgency level based on the calculatedjerk.

In a 169th example, the ambulatory medicament device of any of examples167-168, wherein the alarm response signal is one of: an alarm snoozesignal configured to snooze the alarm or an alarm acknowledgement signalconfigured to dismiss the alarm.

In a 170th example, the ambulatory medicament device of example 169,wherein the hardware processor is further configured to execute thespecific computer-executable instructions to at least: receive an alarmacknowledgement signal from the subject; and in response to receivingthe alarm acknowledgement signal, resume administering the medicament tothe subject.

In a 171st example, the ambulatory medicament device of example 170,wherein the alarm acknowledgement signal is configured to be detected bythe motion sensor and is one of: a gesture input or a touch input.

In a 172nd example, the ambulatory medicament device of any of examples167-171 further comprising a touchscreen controller configured to outputdisplay signals configured to generate user interface screens on atouchscreen and to receive user input signals corresponding to userinteraction with the touchscreen, and wherein the hardware processor isfurther configured to execute the specific computer-executableinstructions to at least: generate a graphical display of the alarm onthe touchscreen, the graphical display including information about thealarm and an alarm acknowledgement touch user interface element; receivean alarm acknowledgement signal from the user via the touchscreen; andin response to receiving the alarm acknowledgement signal, resumeadministering the medicament to the subject.

In a 173rd example, the ambulatory medicament device of example 166,wherein the hardware processor is further configured to execute thespecific computer-executable instructions to at least: in response todetermining that the jerk exceeds the threshold value, restart theambulatory medicament device.

In a 174th example, the ambulatory medicament device of any of examples166-173, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: in responseto determining that the jerk exceeds the threshold value, perform adiagnostic test on the ambulatory medicament pump; and in response tothe ambulatory medicament pump passing the diagnostic test, resumeadministering the medicament to the subject.

In a 175th example, the ambulatory medicament device of example 174,wherein the hardware processor is further configured to execute thespecific computer-executable instructions to at least: in response tothe ambulatory medicament pump failing the diagnostic test, generate analarm indicating that the pump is damaged.

In a 176th example, the ambulatory medicament device of any of examples174-175, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: in responseto the ambulatory medicament pump failing the diagnostic test, restartthe ambulatory medicament device.

In a 177th example, the ambulatory medicament device of any of examples154-176, wherein the motion sensor comprises an accelerometer.

In a 178th example, the ambulatory medicament device of example 177,wherein the hardware processor is configured to detect the freefallmotion of the ambulatory medicament device by: detecting a zero outputfrom the accelerometer.

In a 179th example, the ambulatory medicament device of any of examples177-178, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: in responseto detecting the freefall motion, detect an end to the freefall motionby receiving a baseline output from the accelerometer.

In a 180th example, the ambulatory medicament device of example 179,wherein the baseline output is equal to the acceleration of gravity.

In a 181st example, the ambulatory medicament device of any of examples179-180, wherein the baseline output is within a range of accelerationvalues surrounding the acceleration of gravity, wherein the range ofacceleration values encompasses accelerations felt by the ambulatorymedicament device while attached to the subject.

In a 182nd example, the ambulatory medicament device of any of examples154-181, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: pausedelivery of the medicament for a period of time.

In a 183rd example, the ambulatory medicament device of example 182,wherein the period of time is one of: one minute, five minutes, tenminutes, thirty minutes, an hour, or an amount of time defined by thesubject.

In a 184th example, the ambulatory medicament device of any of examples154-183, wherein the hardware processor is configured to execute thespecific computer-executable instructions to at least: in response todetecting the freefall motion, pause delivery of the medicament untilone of: an end of the freefall motion is detected, an alarm confirmationsignal is received from the subject, or the ambulatory medicament pumppasses a diagnostic test.

In a 185th example, an ambulatory medicament device configured to managea medicament therapy regimen based on motion data associated withmovement of the ambulatory medicament device, the ambulatory medicamentdevice comprising: a medicament reservoir configured to store amedicament; an ambulatory medicament pump configured to deliver themedicament from the medicament reservoir to a subject; a motion sensorconfigured to collect the motion data; a memory configured to storespecific computer-executable instructions; and a hardware processor incommunication with the memory and configured to execute the specificcomputer-executable instructions to at least: detect an alarm condition;generate an alarm; detect an alarm response from the subject based onthe motion data; and silence the alarm based on the alarm responsereceived from the subject.

In a 186th example, the ambulatory medicament device of example 185,wherein the motion sensor is an accelerometer configured to record themotion data, the motion data including an acceleration of the ambulatorymedicament device caused by the alarm response.

In a 187th example, the ambulatory medicament device of any of examples185-186, wherein the alarm response is one of: a single tap, a doubletap, multi-tap, or a multi-location tap on a body of the ambulatorymedicament device or a shaking of the ambulatory medicament device.

In a 188th example, the ambulatory medicament device of any of examples185-187, wherein the hardware processor is further configured todetermine whether the alarm response is an alarm snooze response or analarm acknowledgement response.

In a 189th example, the ambulatory medicament device of any of examples185-188, wherein the alarm response is an alarm snooze response, andwherein the hardware processor is further configured to execute thespecific computer-executable instructions to at least: snooze the alarmfor a period of time, wherein the period of time is determined based onan urgency level of the alarm.

In a 190th example, the ambulatory medicament device of example 189,wherein the hardware processor is further configured to execute thespecific computer-executable instructions to at least: generate a secondalarm after the period of time has elapsed; receive an alarmacknowledgement response; and dismiss the alarm.

In a 191st example, the ambulatory medicament device of any of examples185-190, wherein the alarm response is an alarm acknowledgementresponse, and wherein the hardware processor is further configured toexecute the specific computer-executable instructions to at least:dismiss the alarm.

In a 192nd example, the ambulatory medicament device of any of examples185-191, wherein the alarm is one of: a low-level alarm, a medium-levelalarm, or a high-level alarm, wherein a level of the alarm is determinedbased on the alarm condition.

In a 193rd example, the ambulatory medicament device of any of examples185-192, wherein the alarm has an urgency level between 0 and 5, whereinthe urgency level is determined based on the alarm condition.

In a 194th example, the ambulatory medicament device of any of examples185-193, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: generate thealarm based on an urgency level associated with the alarm condition.

In a 195th example, the ambulatory medicament device of any of examples185-194 further comprising a touchscreen controller configured to outputdisplay signals configured to generate user interface screens on atouchscreen and to receive user input signals corresponding to userinteraction with the touchscreen, wherein the hardware processor isfurther configured to execute the specific computer-executableinstructions to at least: generate a graphical display of the alarm onthe touchscreen; and receive the alarm response through a touch userinterface implemented on the touchscreen.

In a 196th example, the ambulatory medicament device of example 195,wherein the graphical display includes alarm information, an alarmsnooze touch user interface element, and an alarm acknowledgement touchuser interface element.

In a 197th example, the ambulatory medicament device of any of examples195-196, wherein the graphical display is arranged and colored based onan urgency level of the alarm condition.

In a 198th example, the ambulatory medicament device of any of examples185-197 further comprising a speaker, and wherein the hardware processoris further configured to execute the specific computer-executableinstructions to at least: generate an audible signal through the speakerbased on an urgency of the alarm condition.

In a 199th example, the ambulatory medicament device of example 198,wherein the audible signal comprises one of: a beep, a series of beeps,a patterned beeping, or a speech output describing the alarm.

In a 200th example, the ambulatory medicament device of any of examples185-199 further comprising a haptic motor, wherein the hardwareprocessor is further configured to execute the specificcomputer-executable instructions to at least: generate a haptic alarmsignal through the haptic motor based on an urgency of the alarmcondition.

In a 201st example, the ambulatory medicament device of example 200,wherein the haptic signal comprises one of: a sustained vibration, aburst vibration, or a vibration pattern.

In a 202nd example, an ambulatory medicament device configured to managea medicament therapy regimen based on motion data associated withmovement of the ambulatory medicament device, the ambulatory medicamentdevice comprising: a touchscreen controller configured to output displaysignals configured to generate user interface screens on a touchscreenand to receive user input signals corresponding to user interaction withthe touchscreen; a motion sensor configured to collect the motion data;a memory configured to store specific computer-executable instructions;and a hardware processor in communication with the memory and configuredto execute the specific computer-executable instructions to at least:receive a touch input from a subject; determine whether an alarm isactive; and in response to determining there are no alarms pending, wakethe touchscreen.

In a 203rd example, the ambulatory medicament device of example 202,wherein the touch input is received through the touchscreen.

In a 204th example, the ambulatory medicament device of any of examples202-203, wherein the motion sensor comprises an accelerometer, andwherein the motion data includes an acceleration of the ambulatorymedicament device.

In a 205th example, the ambulatory medicament device of example 204,wherein the hardware processor is further configured to execute thespecific computer executable instructions to at least: receive the touchinput by detecting an acceleration of the ambulatory medicament devicecaused by the touch input.

In a 206th example, the ambulatory medicament device of any of examples202-205, wherein the touch input comprises one or more of: a single tap,a double tap, multi-tap, a multi-location tap, a pinch gesture, or aswipe gesture.

In a 207th example, the ambulatory medicament device of any of examples202-206, wherein the touch input comprises one or more touches on one ormore corners of the touchscreen.

In a 208th example, the ambulatory medicament device of example 207,wherein the touch input comprises a first touch on a first corner of thetouchscreen, a second touch on a second corner of the touchscreen, and athird touch on a third corner of the touchscreen.

In a 209th example, the ambulatory medicament device of any of examples202-208, wherein the touch input comprises one or more touches on theambulatory medicament device.

In a 210th example, the ambulatory medicament device of any of examples202-209, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: unlock thetouchscreen and the ambulatory medicament device based on the touchinput.

In a 211th example, the ambulatory medicament device of example 210,wherein the touch input comprises a gesture password, and wherein thehardware processor is further configured to execute the specificcomputer-executable instructions to at least: determine whether thegesture password matches a stored password; and in response todetermining that the gesture password matches a stored password, unlockthe touchscreen and the ambulatory medicament device.

In a 212th example, the ambulatory medicament device of any of examples202-211, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: in responseto determining that there are no alarms pending, wake the touchscreenby: displaying a home screen.

In a 213th example, the ambulatory medicament device of any of examples202-212, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: in responseto determining that there are no alarms pending, wake the touchscreenby: displaying an unlock display on the touchscreen, the unlock displaycomprising a touch user interface element configured to unlock thedevice.

In a 214th example, the ambulatory medicament device of any of examples202-213, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: receive, viathe touchscreen, a second touch input comprising a gesture password;determine whether the gesture password matches a stored password; and inresponse to determining that the gesture password matches a storedpassword, unlock the touchscreen.

In a 215th example, an ambulatory medicament device configured toadminister a medicament therapy dose based on motion data associatedwith movement of the ambulatory medicament device, the ambulatorymedicament device comprising: a medicament reservoir configured to storea medicament; an ambulatory medicament pump configured to deliver themedicament from the medicament reservoir to a subject; a motion sensorconfigured to collect the motion data; a memory configured to storespecific computer-executable instructions; and a hardware processor incommunication with the memory and configured to execute the specificcomputer-executable instructions to at least: detect a touch input basedon the motion data; and in response to detecting the touch input,deliver a medicament dose.

In a 216th example, the ambulatory medicament device of example 215,wherein the medicament is one of: insulin or glucagon.

In a 217th example, the ambulatory medicament device of any of examples215-216, wherein the motion sensor comprises an accelerometer, andwherein the motion data includes an acceleration of the ambulatorymedicament device.

In a 218th example, the ambulatory medicament device of example 217,wherein the hardware processor is further configured to execute thespecific computer-executable instructions to at least: detect the touchinput based on an acceleration of the ambulatory medicament devicecaused by the touch input.

In a 219th example, the ambulatory medicament device of any of examples215-218, wherein the touch input comprises one or more of: a single tap,a double tap, a triple tap, a multi tap, a multi-location tap, a pinchgesture, or a swipe gesture.

In a 220th example, the ambulatory medicament device of any of examples215-219, wherein the touch input comprises one or more touches on one ormore corners of the device.

In a 221st example, the ambulatory medicament device of example 220,wherein the touch input comprises a first touch on a first corner of thedevice, a second touch on a second corner of the device, and a thirdtouch on a third corner of the device.

In a 222nd example, the ambulatory medicament device of any of examples215-221, wherein the touch input comprises a sequence of one or moretouches on one or more locations on the ambulatory medicament device.

In a 223rd example, the ambulatory medicament device of example 222,wherein the one or more locations comprises: a front of the device, oneor more sides of the device, and a rear of the device.

In a 224th example, the ambulatory medicament device of any of examples215-223, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: in responseto detecting the touch input, prompt the subject to confirm themedicament dose; detect a second touch input based on the motion data,the second touch input configured to confirm the medicament dose; and inresponse to detecting the second touch input from the subject, deliverthe medicament dose.

In a 225th example, the ambulatory medicament device of any of examples215-224 further comprising a touchscreen controller configured to outputdisplay signals configured to generate user interface screens on atouchscreen and to receive user input signals corresponding to userinteraction with the touchscreen, wherein the hardware processor isfurther configured to execute the specific computer-executableinstructions to at least: in response to detecting the touch input,prompt the subject, via the touchscreen, to confirm the medicament dose;detect a second touch input based on the motion data, the second touchinput configured to confirm the medicament dose; and in response todetecting the second touch input from the subject, deliver themedicament dose.

In a 226th example, the ambulatory medicament device of any of examples215-225 further comprising a speaker configured to generate audioprompts, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: in responseto detecting the touch input, prompt the subject, via the speaker, toconfirm the medicament dose; detect a second touch input based on themotion data, the second touch input configured to confirm the medicamentdose; and in response to detecting the second touch input from thesubject, deliver the medicament dose.

In a 227th example, the ambulatory medicament device of any of examples215-226 further comprising a haptic motor configured to generatevibration signals on a body of the subject, wherein the hardwareprocessor is further configured to execute the specificcomputer-executable instructions to at least: in response to detectingthe touch input, generate a vibration signal to prompt the subject toconfirm the medicament dose; detect a second touch input based on themotion data, the second touch input configured to confirm the medicamentdose; and in response to detecting the second touch input from thesubject, deliver the medicament dose.

In a 228th example, the ambulatory medicament device of any of examples215-227, wherein the hardware processor is further configured to executethe specific computer-executable instructions to at least: monitor ablood sugar level of the subject; determine a need for a bolusmedicament dose based on the blood sugar level of the subject; and inresponse to determining a need for the bolus medicament dose, prompt thesubject to initiate the medicament bolus dose by entering the touchinput.

Terminology

It is to be understood that not necessarily all objects or advantagesmay be achieved in accordance with any particular embodiment describedherein. Thus, for example, those skilled in the art will recognize thatcertain embodiments may be configured to operate in a manner thatachieves or optimizes one advantage or group of advantages as taughtherein without necessarily achieving other objects or advantages as maybe taught or suggested herein.

All of the processes described herein may be embodied in, and fullyautomated via, software code modules executed by a computing system thatincludes one or more computers or processors. The code modules may bestored in any type of non-transitory computer-readable medium or othercomputer storage device. Some or all the methods may be embodied inspecialized computer hardware. Further, the computing system mayinclude, be implemented as part of, or communicate with an automatedblood glucose system, an ambulatory medicament system, or an ambulatorymedical device.

Many other variations than those described herein will be apparent fromthis disclosure. For example, depending on the embodiment, certain acts,events, or functions of any of the algorithms described herein can beperformed in a different sequence, can be added, merged, or left outaltogether (for example, not all described acts or events are necessaryfor the practice of the algorithms). Moreover, in certain embodiments,acts or events can be performed concurrently, for example, throughmulti-threaded processing, interrupt processing, or multiple processorsor processor cores or on other parallel architectures, rather thansequentially. In addition, different tasks or processes can be performedby different machines and/or computing systems that can functiontogether.

The various illustrative logical blocks and modules described inconnection with the embodiments disclosed herein can be implemented orperformed by a machine, such as a processing unit or processor, adigital signal processor (DSP), an application specific integratedcircuit (ASIC), a field programmable gate array (FPGA) or otherprogrammable logic device, discrete gate or transistor logic, discretehardware components, or any combination thereof designed to perform thefunctions described herein. A processor can be a microprocessor, but inthe alternative, the processor can be a controller, microcontroller, orstate machine, combinations of the same, or the like. A processor caninclude electrical circuitry configured to process computer-executableinstructions. In another embodiment, a processor includes an FPGA orother programmable device that performs logic operations withoutprocessing computer-executable instructions. A processor can also beimplemented as a combination of computing devices, for example, acombination of a DSP and a microprocessor, a plurality ofmicroprocessors, one or more microprocessors in conjunction with a DSPcore, or any other such configuration. Although described hereinprimarily with respect to digital technology, a processor may alsoinclude primarily analog components. A computing environment can includeany type of computer system, including, but not limited to, a computersystem based on a microprocessor, a mainframe computer, a digital signalprocessor, a portable computing device, a device controller, or acomputational engine within an appliance, to name a few.

Conditional language such as, among others, “can,” “could,” “might” or“may,” unless specifically stated otherwise, are otherwise understoodwithin the context as used in general to convey that certain embodimentsinclude, while other embodiments do not include, certain features,elements and/or steps. Thus, such conditional language is not generallyintended to imply that features, elements and/or steps are in any wayrequired for one or more embodiments or that one or more embodimentsnecessarily include logic for deciding, with or without user input orprompting, whether these features, elements and/or steps are included orare to be performed in any particular embodiment.

Disjunctive language such as the phrase “at least one of X, Y, or Z,”unless specifically stated otherwise, is otherwise understood with thecontext as used in general to present that an item, term, etc., may beeither X, Y, or Z, or any combination thereof (for example, X, Y, and/orZ). Thus, such disjunctive language is not generally intended to, andshould not, imply that certain embodiments require at least one of X, atleast one of Y, or at least one of Z to each be present.

Any process descriptions, elements or blocks in the flow diagramsdescribed herein and/or depicted in the attached figures should beunderstood as potentially representing modules, segments, or portions ofcode which include one or more executable instructions for implementingspecific logical functions or elements in the process. Alternateimplementations are included within the scope of the embodimentsdescribed herein in which elements or functions may be deleted, executedout of order from that shown, or discussed, including substantiallyconcurrently or in reverse order, depending on the functionalityinvolved as would be understood by those skilled in the art.

Unless otherwise explicitly stated, articles such as “a” or “an” shouldgenerally be interpreted to include one or more described items.Accordingly, phrases such as “a device configured to” are intended toinclude one or more recited devices. Such one or more recited devicescan also be collectively configured to carry out the stated recitations.For example, “a processor configured to carry out recitations A, B andC” can include a first processor configured to carry out recitation Aworking in conjunction with a second processor configured to carry outrecitations B and C.

Many variations and modifications may be made to the above-describedembodiments, the elements of which are to be understood as being amongother acceptable examples. All such modifications and variations areintended to be included herein within the scope of this disclosure.

What is claimed is:
 1. An ambulatory medicament device configured tomaintain indications of alarm conditions on a list of pending alarmconditions without auditory or haptic annunciation of at least some ofthe alarm conditions while a do not disturb mode is active, theambulatory medicament device comprising: a monitoring system interfaceconfigured to receive status information, wherein the status informationcomprises at least one of device information pertaining to a conditionof the ambulatory medicament device or subject information pertaining toa condition of a subject; a memory configured to store specificcomputer-executable instructions and the list of pending alarmconditions; and a hardware processor in communication with the memoryand configured to execute the specific computer-executable instructionsto at least: receive alarm muting instructions via user interaction withan alarm muting control interface; in response to determining that alarmannunciation should be muted in accordance with the alarm mutinginstructions, activate the do not disturb mode of the ambulatorymedicament device, wherein at least some alarm annunciation patterns arenot aurally or haptically annunciated while the ambulatory medicamentdevice is in the do not disturb mode; detect, via the monitoring systeminterface, that the status information or the subject informationindicates at least one of a first alarm condition, a second alarmcondition, or a third alarm condition; determine that the first alarmcondition requires urgent user attention; in response to determiningthat the first alarm condition requires urgent user attention,annunciate the first alarm condition, without deactivating the do notdisturb mode, using a first alarm condition annunciation patterncomprising at least one of auditory or haptic annunciation; maintain anindication of the first alarm condition on the list of pending alarmconditions until the first alarm condition is resolved; determine thatthe second alarm condition does not require urgent user attention; inresponse to determining that the second alarm condition does not requireurgent user attention, maintain an indication of the second alarmcondition on the list of pending alarm conditions until the second alarmcondition is resolved without auditory or haptic annunciation of thesecond alarm condition while the do not disturb mode is active;determine that the third alarm condition does not require urgent userattention and that the third alarm condition has lower priority than thesecond alarm condition; and upon deactivation of the do not disturbmode, annunciate the second alarm condition without auditory or hapticannunciation of the third alarm condition.
 2. The ambulatory medicamentdevice of claim 1, wherein the hardware processor is configured toexecute further computer-executable instructions to, in response todetermining that the first alarm condition requires urgent userattention, deactivate the do not disturb mode.
 3. The ambulatorymedicament device of claim 1, wherein determining that the first alarmcondition requires urgent user attention comprises: determining aseverity level of the first alarm condition; and determining that theseverity level of the first alarm condition exceeds a threshold severitylevel.
 4. The ambulatory medicament device of claim 1, wherein the alarmmuting control interface comprises a touchscreen controller configuredto output display signals configured to generate user interface screenson a touchscreen and to receive user input signals corresponding to userinteraction with the touchscreen.
 5. The ambulatory medicament device ofclaim 1, wherein the alarm muting instructions comprise a recurring timeinterval, wherein the hardware processor is configured to executefurther computer-executable instructions to activate the do not disturbmode during the recurring time interval.
 6. The ambulatory medicamentdevice of claim 5, wherein the recurring time interval comprises a timeinterval occurring every day between 18:00 and 07:00.
 7. The ambulatorymedicament device of claim 1, wherein the alarm muting control interfaceis part of a remote device that is separate from the ambulatorymedicament device.
 8. The ambulatory medicament device of claim 1,wherein the list of pending alarm conditions is sorted according toseverity levels of alarm conditions included on the list of pendingalarm conditions.
 9. The ambulatory medicament device of claim 1,wherein the list of pending alarm conditions is displayed on a userinterface of the ambulatory medicament device.
 10. The ambulatorymedicament device of claim 9, wherein the list of pending alarmconditions comprises alarm status indicators, wherein the alarm statusindicators indicate whether pending alarm conditions in the list ofpending alarm conditions were annunciated or muted.
 11. The ambulatorymedicament device of claim 1, wherein the alarm muting instructionscomprise a time period during which the do not disturb mode is to remainactive, wherein the hardware processor is configured to execute furthercomputer-executable instructions to deactivate the do not disturb modeafter the time period has passed.
 12. The ambulatory medicament deviceof claim 11, wherein the hardware processor is configured to executefurther computer-executable instructions to: receive via userinteraction with the alarm muting control interface, prior totermination of the time period, instructions to deactivate the do notdisturb mode; and deactivate the do not disturb mode.
 13. The ambulatorymedicament device of claim 1, wherein the hardware processor isconfigured to execute further computer-executable instructions to:determine the second alarm condition has not been resolved for athreshold amount of time; escalate the second alarm condition such thatthe second alarm condition requires urgent user attention; and inresponse to determining that the second alarm condition requires urgentuser attention, annunciate the second alarm condition using a secondalarm condition annunciation pattern comprising at least one of auditoryor haptic annunciation.
 14. The ambulatory medicament device of claim 1wherein resolving alarm conditions comprises at least one of: correctingthe alarm conditions, acknowledging the alarm conditions, or snoozingthe alarm conditions.
 15. The ambulatory medicament device of claim 14,wherein correcting the alarm conditions comprises one or more actionstaken by a user that address a condition which caused an alarm to begenerated.
 16. The ambulatory medicament device of claim 1, wherein thefirst alarm condition is resolved automatically when the statusinformation or the subject information no longer indicates the firstalarm condition.
 17. The ambulatory medicament device of claim 1,wherein the hardware processor is configured to execute furthercomputer-executable instructions to maintain an indication of the thirdalarm condition on the list of pending alarm conditions until the thirdalarm condition is resolved without auditory or haptic annunciation ofthe third alarm condition.
 18. A glucose control system comprising: amonitoring system interface configured to receive status information,wherein the status information comprises at least one of deviceinformation pertaining to a condition of the glucose control system orsubject information pertaining to a condition of a subject; a memoryconfigured to store specific computer-executable instructions and a listof pending alarm conditions; and a hardware processor in communicationwith the memory and configured to execute the specificcomputer-executable instructions to at least: receive alarm mutinginstructions via user interaction with an alarm muting controlinterface; in response to determining that alarm annunciation should bemuted in accordance with the alarm muting instructions, activate a donot disturb mode of the glucose control system, wherein at least somealarm annunciation patterns are muted while the glucose control systemis in the do not disturb mode; detect, via the monitoring systeminterface, that the status information or the subject informationindicates an alarm condition; determine that the alarm condition doesnot require urgent user attention; and in response to determining thatthe alarm condition does not require urgent user attention, maintain anindication of the alarm condition on the list of pending alarmconditions until the alarm condition is resolved without auditory orhaptic annunciation of the alarm condition while the do not disturb modeis active.
 19. The glucose control system of claim 18, wherein the listof pending alarm conditions is sorted according to severity levels ofalarm conditions included on the list of pending alarm conditions. 20.The glucose control system of claim 19, wherein the hardware processoris configured to execute further computer-executable instructions to,upon deactivation of the do not disturb mode, annunciate a most severealarm condition, based on the severity levels of the alarm conditionsincluded on the list of pending alarm conditions.
 21. The glucosecontrol system of claim 18, wherein the hardware processor is configuredto execute further computer-executable instructions to: detect, via themonitoring system interface, a second alarm condition; determine thatthe second alarm condition requires urgent user attention; and inresponse to determining that the second alarm condition requires urgentuser attention, deactivate the do not disturb mode.
 22. The glucosecontrol system of claim 18, wherein the hardware processor is configuredto execute further computer-executable instructions to: detect, via themonitoring system interface, a second alarm condition; determine thatthe second alarm condition requires urgent user attention; and inresponse to determining that the second alarm condition requires urgentuser attention, annunciate the second alarm condition withoutdeactivating the do not disturb mode, using a second alarm conditionannunciation pattern comprising at least one of auditory or hapticannunciation.
 23. The glucose control system of claim 18, wherein thelist of pending alarm conditions comprises alarm status indicators,wherein the alarm status indicators indicate whether pending alarmconditions in the list of pending alarm conditions were annunciated ormuted.
 24. The glucose control system of claim 18, wherein the alarmmuting control interface comprises a touchscreen controller configuredto output display signals configured to generate user interface screenson a touchscreen and to receive user input signals corresponding to userinteraction with the touchscreen.
 25. A method of annunciating alarmsassociated with a glucose control system, the method comprising:receiving alarm muting instructions via user interaction with an alarmmuting control interface; in response to determining that alarmannunciation should be muted in accordance with the alarm mutinginstructions, activating a do not disturb mode of the glucose controlsystem, wherein at least some alarm annunciation patterns are mutedwhile the glucose control system is in the do not disturb mode;detecting that an alarm condition exists; determining that the alarmcondition does not require urgent user attention; and in response todetermining that the alarm condition does not require urgent userattention, maintain an indication of the alarm condition on a list ofpending alarm conditions until the alarm condition is resolved withoutauditory or haptic annunciation of the alarm condition while the do notdisturb mode is active.
 26. The method of claim 25, wherein detectingthat an alarm condition exists comprises detecting that at least one ofdevice information pertaining to a condition of the glucose controlsystem or subject information pertaining to a condition of a subjectindicates an alarm condition.
 27. The method of claim 25, whereinreceiving the alarm muting instructions comprises receiving, via userinteraction with the alarm muting control interface, a time periodduring which the do not disturb mode is to remain active.
 28. The methodof claim 27, further comprising: receiving, via user interaction withthe alarm muting control interface, prior to termination of the timeperiod, instructions to deactivate the do not disturb mode; anddeactivating the do not disturb mode.
 29. The method of claim 25,further comprising: detecting a second alarm condition; determining thatthe second alarm condition requires urgent user attention; and inresponse to determining that the second alarm condition requires urgentuser attention, deactivating the do not disturb mode.
 30. The method ofclaim 25, further comprising: detecting a second alarm condition;determining that the second alarm condition requires urgent userattention; and in response to determining that the second alarmcondition requires urgent user attention, annunciating the second alarmcondition without deactivating the do not disturb mode, using a secondalarm condition annunciation pattern comprising at least one of auditoryor haptic annunciation.